On Thu, 06.11.14 18:32, Michael Marineau ([email protected]) wrote:
> On Thu, Nov 6, 2014 at 6:02 PM, Lennart Poettering > <[email protected]> wrote: > > On Thu, 06.11.14 17:48, Michael Marineau ([email protected]) > > 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
