[systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit

[Lennart Poettering]

On Thu, 06.11.14 17:48, Michael Marineau (michael.marineau at coreos.com) wrote:

> > So, what's the real usecase for all of this? Can you elaborate on
> > that?
> 
> The basic idea is to create a container that has the ability to return a
> normal exit code when it exits. System instances don't allow this. 

Well, but this is something we could allow. In fact our shutdown code
invokes exit(0) if reboot() returns EPERM already (in case of
CAP_SYS_BOOT is missing). That said, note that in a PID namespace
reboot() nowadays results in the equivalent of raise(SIGINT) anyway,
which isn't too different from a simple exit().

> User instances do and also avoid other undesired things like reading
> extra args from /proc/cmdline which isn't applicable to a container.

There's already an explicit check in place that makes sure read
/proc/1/cmdline in place of of /proc/cmdline if we detect we are run
in a container:

http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n6174

> There seems to be a odd fit here between expecting a system instance to
> behave nicely like yet another service on a host or a user instance to be
> pid 1 in a container.

Hmm, so what you are trying to do running one systemd instance as a
service on another one, in a way that they see the same file hiearchy
but operate based on unit files in a different directory? Is that
correct? Wouldn't a container (maybe nspawn) work for this with some
clevery set up --bind= mounts?

Lennart

-- 
Lennart Poettering, Red Hat