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(). > 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
