Hello, Ludo's FOSDEM talk inspired me to share some thoughts that I encountered during my time at my previous position where we designed an init system.
This might be better targeted specifically for shepherd, in this case please redirect and let me know. The fist things are the specialities of the pid 1 processes: - they own the pid namespace where they are pid 1 (this works automatically, there is nothing to do here) - they do not have default signal handling (this means that when running as pid1 you might want to have a default set of signal handlers installed) - the orphaned processes from the pid namespace get automatically reparented to them (on linux there is a concept called a subreaper process that allows to delegate this responsibility downwards, having the orphaned processes reparented to the subreapers, to be able to manage process subtrees without the need to spin up a new nested pid namespace, we might want to provide configuration to enable the subreaper behavior) Also, now pid 1 exist on all pid namespace of the pid namespace hierarchy, and also from the outer nesting levels these are also visible under a different pid. We might take a look how shepherd interacts with these. On the process management front a quite important new API is available in newer linux kernels, called pidfd, which allows to have a file descriptor interface to a process, making signaling and waiting for processes much less error prone. Tbh. I did not have time to do my homework yet on the shepherd internals, so it might well be that some things from the above are already there, maybe someone can advise on the status and if there is some interest in any of these aspects. Regards, g_bor
