Re: Shepherd and minimalism in pid 1

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <gboskovits@gmail.com> skribis:

> 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.

Oh!

> 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)

I was aware of this so hopefully this is all good.

> 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.

Agreed.  In commit f6a77c1ab28f07c496f799ff0bdb953b1fe628b2,
‘gnu-build-system.scm’ was changed precisely for that reason: so that
PID 1 would take care of reaping dead processes, which was not the case
before and a source of problems (see <https://issues.guix.gnu.org/30948>.)

> 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.

Yup, pidfd looks nice!  So far, the overall design decision was to try
and avoid relying on Linux interfaces not implemented on the Hurd.  For
‘signalfd’, there’s a fallback to good old signal handlers when not
running on Linux; it’s less pleasant than ‘signalfd’ and it increases
the surface to test, so I’d rather not do it too much.

If you take a look at the Shepherd’s code, do share your findings.

Thanks for your feedback!

Ludo’.