Re: init / supervisor in jail

On 2025-11-10 04:27, Andriy Gapon wrote:
> I played a little bit with OCI containers and podman.
> I had a hiccup with one specific container created for Docker / Linux.
> Its difference from other containers is that it uses multiple daemons 
> and a supervisor process to take care of them.  That particular 
> supervisor is another variation of "advanced init", it's called s6.  
> Apparently, it is relatively popular for container use (not sure about 
> host systems).  Probably other alternatives can be / are used for that 
> purpose as well.
> 
> I think that this is what a supervisor in a container needs:
> 1. its PID is 1;
> 2. orphaned processes get re-parented to it.
> 
> I think that (1) is not a hard requirement, but it's an easy way to 
> check if the process would be able to work as init.
> Also, some other processes might expect to find init at PID 1, but I am 
> not sure about that.
> 
> (2) is important for doing the supervising (at least, when 
> procctl(PROC_REAP*) is not used) .
> 
> I think that on Linux they have separate PID namespace per container, 
> so the first process to run naturally gets PID 1.
> 
> I think that per-container PID namespace may be an overkill.
> Maybe there is a way to make PID 1 special without going that way.
> 
> E.g., a jail could record the first process it runs.
> We can patch up getpid() to return 1 for that process.
> Also, we could patch up the process lookup to return the first process 
> in the jail for PID 1.
> 
> Re-parenting to the "jail init" sounds harder but should be possible as 
> well (e.g., using PROC_REAP).
> 
> Not sure what to do if the "jail init" dies... should all processes in 
> the jail get killed and the jail should die as well (unless 
> persistent)?
> 
> This proposal sounds like a kludge but it could be a shortcut to 
> support more Linux containers and to allow similar FreeBSD jails / 
> containers with alternative init-s / supervisors.

Far from being a kludge, I think it's a feature we need, and one at the 
top of my list.  Forcing it to look like PID 1 from jailed perspective 
is definitely doable (and something I'd done outside of the project a 
decade ago).  In addition to those two requirements, I would add one 
that answers your last question:

3. signals to init and reboot(2) work as they would on the host side.

A jailed reboot would kill all processes and restart rc, and possibly do 
other kernel-side cleanups yet to be clearly defined.  A jailed halt 
would remove the jail.  A jailed single-user mode could exist where 
instead of init spawning a shell, it just sits around while the system 
has a chance to jexec into it.

init handles various signals by rebooting/halting/etc, and it should be 
able to do that as it does now, by calling reboot(2), directing the 
kernel to do what it needs to with the jail.  If init goes away, it's 
probably like a halt and removes the jail.

This is definitely something that will be happening.

- Jamie