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

[Lennart Poettering]

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

> On Thu, Nov 6, 2014 at 6:02 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > 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().
> 
> The trick then is just reworking that to support plumbing through an
> exit code to exit() instead.

Yeah, I'd be willing to take a patch for this. But the patch should
refuse such an Exit()/ExitWitCode() invocation unless we are in either
--user mode, or in --system mode inside of a container. i.e. if we run
outside of a container in --system mode the Exit() call should return
with permission denied or so.

> > 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?
> 
> I nspawn (or similar? I'm not actually part of this particular
> project) is being used here, hence running as PID 1. Running the
> instance as --user seemed like the more fruitful way to plumb through
> an exit code but fixing --system probably would fit our needs too.

Yes, making --system work like you need it sounds much preferable to me.

Lennart

-- 
Lennart Poettering, Red Hat