[
https://issues.apache.org/jira/browse/MESOS-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16697532#comment-16697532
]
Till Toenshoff commented on MESOS-9397:
---------------------------------------
The macOS 10.14.2 (beta3) documentation (manpage) for {{setrlimit}} states the
following:
{quote}Only the super-user may raise the maximum limits. Other users may only
alter rlim_cur within the range from 0 to rlim_max or (irreversibly) lower
rlim_max.{quote}
When running {{getrlimit}} for {{RLMT_CORE}} on the current user, the system
returns {{0, 0}} for me.
The test tries to set the limits to {{RLIM_INFINITY, RLIM_INFINITY}}
(0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFFF) which is way over {{0, 0}}, so the
failure makes sense and does not seem like a beta-quirk at all.
When running {ulimit} to get the current limits for core dumps, the returned
values fit the system function calls mentioned above:
{noformat}
$ ulimit -H -c
0
$ ulimit -S -c
0
{noformat}
Now comes the interesting part, when using the macOS way of getting limits (as
a normal user):
{noformat}
$ launchctl limit
cpu unlimited unlimited
filesize unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 2837 4256
maxfiles 256 unlimited
{noformat}
This hints that there is a weird quirk in my shell setup as it responds with a
hard limit of {{0}} while launch control returns {{unlimited}}.
I then went ahead and tried it on a different machine with macOS 10.14.2
(beta3) installed; the results there were different / correct, negating results
on the machine I used when reporting the issue - again hinting that my shell is
somewhat broken. While I still don't know what breaks my shell, it now became
clear that the recent beta of macOS was not at fault.
The fact that our rlimits {{set}} function assumes an unlimited hard limit for
core dumps however appears a bit dangerous, as my example has shown.
> PosixRLimitsIsolatorTest.UnsetLimits is broken on macOS 10.14.2 beta3.
> ----------------------------------------------------------------------
>
> Key: MESOS-9397
> URL: https://issues.apache.org/jira/browse/MESOS-9397
> Project: Mesos
> Issue Type: Bug
> Components: test
> Affects Versions: 1.8.0
> Environment: macOS 10.14.2 Beta 3 (18C38b)
> Apple LLVM version 10.0.0 (clang-1000.11.45.5)
> cmake version 3.12.4
> ninja 1.8.2
> Reporter: Till Toenshoff
> Priority: Major
> Labels: test
>
> It appears that changes in macOS are now preventing the setup of rlimit for
> non root users.
> {noformat}
> 3: [ RUN ] PosixRLimitsIsolatorTest.UnsetLimits
> 3: Failed to set RLMT_CORE limit: Failed to set rlimit: Operation not
> permitted
> 3: ../src/tests/containerizer/posix_rlimits_isolator_tests.cpp:194: Failure
> 3: Expected: TASK_STARTING
> 3: To be equal to: statusStarting->state()
> 3: Which is: TASK_FAILED
> 3: ../src/tests/containerizer/posix_rlimits_isolator_tests.cpp:196: Failure
> 3: Failed to wait 15secs for statusRunning
> 3: ../src/tests/containerizer/posix_rlimits_isolator_tests.cpp:185: Failure
> 3: Actual function call count doesn't match EXPECT_CALL(sched,
> statusUpdate(&driver, _))...
> 3: Expected: to be called 3 times
> 3: Actual: called once - unsatisfied and active
> 3: [ FAILED ] PosixRLimitsIsolatorTest.UnsetLimits (15209 ms)
> {noformat}
> It is still unclear if this was just a beta-quirk or intended behaviour in
> upcoming macOS versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
