control: retitle -1 websockify: FTBFS with systemd (>= 256~rc3-3) due to fileno limit bump
Hi, On 2024-07-06 11:54, Graham Inggs wrote: > Source: websockify > Version: 0.10.0+dfsg1-6 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: debian-ri...@lists.debian.org > > Hi Maintainer > > Since the recent binNMU for Python 3.12 as default, websockify FTBFS > on riscv64 [1], where it built previously. I've copied what I hope > is the relevant part of the log below. > > Currently builds time out after 10 hours, where previous builds would > complete successfully in 10 - 20 minutes. > > This is blocking the transition to Python 3.12 as default. The problem is not limited to riscv64, but can be reproduced on an up to date amd64 testing/sid installation. Depending on the amount of swap available, the result could be an OOM or a FTBFS. In my test it OOmed after allocating around 60 GB. I tracked down the issue to the increase of open file limit in systemd 256~rc3-3 [1] from 1048576 to 1073741816. In particular this code from websockify/websockifyserver.py is the culprit: | # Close open files | maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1] | if maxfd == resource.RLIM_INFINITY: maxfd = 256 | for fd in reversed(range(maxfd)): Just allocating an array of 1000+ millions entries with range() requires a lot of resources, but it is also reversed and looped over. Regards Aurelien [1] https://tracker.debian.org/news/1533060/accepted-systemd-256rc3-3-source-into-unstable/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
