Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resource.setrlimit (CIME/XML/env_mach_specific.py) always fails on Darwin and should be skipped #4733

Open
phansel opened this issue Jan 14, 2025 · 0 comments

Comments

@phansel
Copy link

phansel commented Jan 14, 2025

This call does not work on macOS/Darwin and will return an error which should be caught and ignored.

https://github.com/ESMCI/cime/blob/master/CIME/XML/env_mach_specific.py#L162:

def _get_resources_for_case(self, case):
    resource_nodes = self.get_children("resource_limits")
    if resource_nodes is not None:
        nodes = self._compute_resource_actions(resource_nodes, case)
        for name, val in nodes:
            attr = getattr(resource, name)
            limits = resource.getrlimit(attr)
            logger.info(
                "Setting resource.{} to {} from {}".format(name, val, limits)
            )
            limits = (int(val), limits[1])
            resource.setrlimit(attr, limits)

If the resource node is identified as macOS, the resource.setrlimit() call should be skipped.

config_machines.xml does not include an architecture or OS parameter, but one can use platform to identify the OS:

>>> import platform
>>> platform.system()
'Darwin'

Some context courtesy of Terry Lambert:

https://ai-fast-downward.dmi.unibas.ch/msg7484

The corresponding information is hard to find, but Mac OS seems to
intentionally provide these APIs (ulimit on the shell, resource.setrlimit in
Python) but ignore them. There is an article on this on lists.apple.com, which
is currently only available on the Wayback Machine:

https://web.archive.org/web/20150908044241/https://lists.apple.com/archives/unix-porting/2005/Jun/msg00115.html

In case this will no longer be available in the future, here is the most
relevant part:

======================================================================================

The setrlimit() administrative limits are not enforced except for certain ones
which are enforcible in BSD code. Those which would require enforcement in Mach
code (VM-based enforcement or scheduler- based enforcement) are not currently
enforced at all.

These administrative limits were never intended to save the system from fragile
code; the way to do that is to make the code less fragile. They historically
date back to the days when CPU time and memory usage were billable resources,
and process accounting and system accounting were used on old timeshare machines
that were purchased by groups, such as several University departments, because
there was no way for a single University department to be able to afford its own
PDP-8. Today, they are basically knobs that have to be there so old code can be
ported, but which don't actually have to do anything, for the most part.

The limits are considered administrative, as they are not intended to permit the
creation of security policy dependencies, nor are they intended to mitigate
problems related to application memory leaks.

The following is the current(0) MacOS X resource limit support table:

------------- ---------    ---------
Limit name    Standard?    Enforced?
------------- ---------    ---------
RLIMIT_CPU      YES          NO
RLIMIT_FSIZE    YES          YES(1)
RLIMIT_DATA     YES          NO
RLIMIT_STACK    YES          YES(1)
RLIMIT_CORE     YES          YES
RLIMIT_AS       YES          NO
RLIMIT_RSS      NO(2)        NO
RLIMIT_MEMLOCK  NO           NO
RLIMIT_NPROC    NO           YES(3)
RLIMIT_NOFILE   YES          YES
------------- ---------    ---------

(0) This table is subject to change.

(1) Not entirely correctly enforced; specifically, boundary conditions are
clipped before or after the boundary, rather than exactly at it.

(2) RLIMIT_RSS is a MACOS X-specific alias for RLIMIT_AS.

(3) Whether this limit is the upper bounds depends on current sysctl settings on
the machine.

See also:

http://www.opengroup.org/onlinepubs/009695399/functions/ setrlimit.html

To determine whether or not a limit is enforced by an OS, rather than using the
return code of setrlimit(), you must first use getrlimit() and compare the
result to RLIM_INFINITY; if it's RLIM_INFINITY, then you should not set a limit
(you can, but you will confuse child processes which call getrlimit() themselves
to check for enforcement, if you do).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant