Control: tags -1 - pending patch
[Following up on the cloned bug 918464 and dropping Santiago from CC.]
On 2019-01-06 18:20 +1100, Dmitry Smirnov wrote:
> On Saturday, 5 January 2019 6:54:39 PM AEDT Sven Joachim wrote:
>> I get a different error here:
>>
>> ,----
>>
>> | ## #916415
>> | timeout 11 ./nocache apt show coreutils 1>>/dev/null
>> | apt: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
>> | Aborted
>> | make[1]: *** [debian/rules:21: override_dh_auto_test] Error 134
>>
>> `----
>
> Exit code suggests that APT is not happy hence timeout have nothing to do
> with that so I suspect this is unrelated to "nocache".
ITYM it has nothing to do with timeout. As the failed assertion comes
from nocache.c, it certainly has to do with nocache. ;-)
> Can you reproduce manually by "apt show coreutils"?
No, but with any program under nocache, e.g. "nocache true".
> Also, on which architecture is this?
Plain amd64.
The good news is that I seem to have found the explanation for the
failed assertion. In line 147 of nocache.c we have
fds_lock = malloc(max_fds * sizeof(*fds_lock));
and malloc obviously returned NULL. With a debug printf statement I
found out that max_fds == 1073741816, with sizeof(*fds_lock) == 40 it is
not too surprising that malloc failed.
Why is max_fds so high? In the systemd changelog I found out the
following:
,----
| systemd (240-2) unstable; urgency=medium
|
| * Don't bump fs.nr_open in PID 1.
| In v240, systemd bumped fs.nr_open in PID 1 to the highest possible
| value. Processes that are spawned directly by systemd, will have
| RLIMIT_NOFILE be set to 512K (hard).
| pam_limits in Debian defaults to "set_all", i.e. for limits which are
| not explicitly configured in /etc/security/limits.conf, the value from
| PID 1 is taken, which means for login sessions, RLIMIT_NOFILE is set to
| the highest possible value instead of 512K. Not every software is able
| to deal with such an RLIMIT_NOFILE properly.
| While this is arguably a questionable default in Debian's pam_limit,
| work around this problem by not bumping fs.nr_open in PID 1.
| (Closes: #917167)
|
| -- Michael Biebl <bi...@debian.org> Thu, 27 Dec 2018 14:03:57 +0100
`----
And this sid system has an uptime of 13 days, so was booted with systemd
240-1 which explains the high RLIMIT_NOFILE. On a freshly booted
laptop, I get max_fds == 1048576 instead, and obviously malloc'ing 40
Megabytes rather than 40 Gigabytes of RAM is easily possible.
I guess I should reboot in the near future. Feel free to close the bug
if you think that dealing with a too high value of RLIMIT_NOFILE is not
possible for nocache.
Cheers,
Sven
