On Tue, Feb 15, 2022 at 12:31 PM Rob Landley <r...@landley.net> wrote: > On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: > > However, if this bug shows-up, probably it means that the system has > > a lot of processes running and a lot of processes created and > > destroyed compared to the max PID available. Thus, the system might be > > incorrectly configured compared with its typical usage which probably > > is the main reason because nobody complained before. > > Nah, a shell script can spin through an awful lot of PIDs pretty fast, and if > you're doing a -j 8 build that has a lot of script snippets (let alone > parallel > autoconf etc) vs something with say a 10 second timeout?
I try the below and it seems to be able to spawn "only" ~1500 processes/second. $ time sh -c 'i=30000; while test $((--i)) != 0; do sleep 0 & done 2>/dev/null' real 0m19.190s user 0m23.062s sys 0m6.732s My memory is hazy on this, but IIRC kernel also actually has some defensive code to not immediately reuse pids which just died. It's interesting to find out why pids are reused that fast on the affected system. Meanwhile: what "timeout" is doing is it tries to get out of the way of the PROG to be launched so that timeout's parent sees PROG (not timeout) as a child. E.g. it can send signals to it, get waitpid notifications if PROG has been stopped with a signal, and such. And PROG also has no spurious "timeout" child. "timeout" exists as an orphaned granchild. Let's go with a solution with fd opened to /proc/PID? _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
