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