On Thu, Nov 6, 2014 at 6:02 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Thu, 06.11.14 17:48, Michael Marineau (michael.marin...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel