control: reopen -1 control: retitle -1 FTBFS with huge file number limit due to testsuite timeouts control: found -1 2.4.7-3 control: severity -1 important
Hi, On 2024-06-16 00:19, Debian FTP Masters wrote: > cups (2.4.7-3) unstable; urgency=medium > . > [ Helge Kreutzmann ] > * Update German man page (2220t) > . > [ Thorsten Alteholz ] > * reintroduce time_t changes that were accidentally deleted > with last upload > (thanks to Michael Hudson-Doyle for this work) > * debian/rules: no test on riscv64 (Closes: #1073046) Thanks for fixing this bug promptly. However it only papers over the real issue, which is not riscv64 specific. riscv64 build daemons run a mix of testing and sid, and are thus affected by some recent changes in systemd. More precisely, systemd 256~rc3-3 bumped the maximum number of open files hard limit from 1048576 to 1073741816 [1]. This value seems to be used for the maxevents argument of an epoll_pwait syscall, which now fails: | epoll_pwait(3, NULL, 1073741816, 1000, NULL, 8) = -1 EINVAL (Invalid argument) Note that the second argument is NULL, as the call to calloc() to allocate the events buffer for 1073741816 events failed and returned NULL. This leads to the corresponding error message in the log file: | X [17/Jun/2024:18:35:01.401971 +0000] cupsdDoSelect() failed - Bad address! The issue is reproducible on an up to date testing system, which has been rebooted since the upgrade to systemd 256. Reducing that limit with ulimit workarounds the issue. Regards Aurelien [1] https://salsa.debian.org/systemd-team/systemd/-/commit/99066f931bb49b43e7282fc1fe8488373bfb81e5 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
