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

[Michael Marineau]

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.

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

Missed that one, some other difference in behaviour mislead us I suppose.

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

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.