>I'm wondering if s6-svscan could have a per-service flag to run
>s6-supervise as PID 1 in a PID namespace.
What business does s6-supervise have being pid 1 in its namespace?
Architecturally it's wrong. s6-supervise is a part of a supervision
tree; you can run it independently, but if you run s6-svscan, then
s6-svscan + the set of s6-supervises is a logically atomic unit.
The clear domain separation is between s6-supervise and the process
it supervises, not between s6-svscan and s6-supervise.
Additionally, s6-supervise was not designed to be a pid 1. It does
some of the tasks a pid 1 has to do (such as reaping any zombie it
gets and... supervising one process) but it is authorized to die,
and there's even an s6-svc command to tell it to do so. I know the
system is more lenient for pid 1 in a namespace, but it is still too
many corner cases that would need to be checked to work right.
If you want to run a service in a namespace, flag-newpidns in the
service directory is what you want. The service runs as pid 1 in the
new namespace, so you have full control over it; it is an indepedent
unit from the supervision tree.
>- The child process must forward signals to all of its child processes.
It doesn't have to be implemented this way, in particular if you're
running a service manager in a container. But yes, a program running as
pid 1 has all the duties of init, including shutting the (sub)system
down when it receives a halt command (here a SIGTERM from its
supervisor). It is what it is.
>- It's an extra process that sits around doing nothing.
Processes are not scarce resources. Logical task separation and
domain boundaries, especially when managing state such as namespaces,
are more important than shaving off a process.
That doesn't mean processes are free and it's okay to have useless
extras hanging around, but as always, it's a trade-off, and here the
extra process makes sense, because the separation between "generic
supervisor for a service" and "head of a hierarchy of processes in
the service" is important.
>- The commands that kill a child process while leaving its children
> alive don't work.
That is true for any service, namespace or not: the service should
clean after itself when its main process gets killed.
If you're running a service in a pid namespace, and it spawns
processes,
what you effectively want is a container, running a full hierarchy of
processes; and that means ensuring your inner pid 1 is suitable as an
init, setting it as a subreaper, and possibly setting up cgroups so
nothing can escape your container. That is the proper design.
You are effectively asking s6-supervise to act as an init for your
container. That isn't what s6-supervise was made for, and your
suggestion blends the boundary between the supervisor and the service,
whereas I think that boundary is essential.
--
Laurent
Received on Tue Apr 21 2026 - 15:21:36 CEST