To make the procctl(PROC_REAP_*) API usable in pid 1 the same way as
in a subreaper, we need to not do this.
Sponsored by: https://www.patreon.com/valpackett
Differential D39996
fork: do not exclude pid 1's children from creating reapsubtrees val_packett.cool on May 7 2023, 7:54 PM. Authored by Tags None Referenced Files
Subscribers
Details
To make the procctl(PROC_REAP_*) API usable in pid 1 the same way as Sponsored by: https://www.patreon.com/valpackett As far as I can tell this shoooouldn't change anything for people not trying to build an init system that uses this API, i.e. probably everyone except me right now?? But I don't know…
Diff Detail
Event TimelineComment Actions Looks like mjg added this second half of the conditional and kib the first, so let's tag them explicitly in case they have an opinion. Comment Actions quoting the commit: While here a bug was discovered: all processes would inherit reap id from the first process spawned by init. This had a side effect of keeping the ID used and when allocation rolls over to the beginning it keeps being skipped. Comment Actions What is gained by having PID 1 acquire sub-reaper status given that it's the reaper? What are the expected semantics for proctl(PROC_REAP_ACQUIRE) in PID 1? Would it be enough to wrap the procctl(…) call with if ( getpid() != 1 ) { … } or is there more to this? Comment Actions IMO it is micro-overoptimization, not a fix for a bug. It is fine as far as init(8) does not use reaper API. There is nothing wrong with the fact that all processes spawned from sh running /etc/rc get the same reaper subtree id, rather it is how the things should be done. init(8) might spawn other processes, mostly getty for historicaly reasons, and then console and terminal sessions get other reapsubtree ids. I do not understand this question. init does not get sub-reaper status neither in stock sources, nor after the proposed patch. Comment Actions (well, *it* – users can already replace init(8) with any alternative…)
Ahh, here I was trying to "reproduce the bug" without using /etc/rc and failing :D Now it makes sense what that commit was referring to. Agreed.
IIUC there isn't a distinct "sub-reaper status", PROC_REAP_ACQUIRE just sets the same flag that pid 1 already gets from birth. In any case yeah, this is not about ACQUIRE at all. |