On Nov 6, 2014 5:17 PM, "Lennart Poettering" <lenn...@poettering.net> wrote: > > On Thu, 06.11.14 16:59, Vito Caputo (vito.cap...@coreos.com) wrote: > > > Because for all intents and purposes it's effectively still a user > > instance, just having its own PID namespace isn't cause --system behaviors > > like disabling systemctl exit for example. > > I am pretty sure doing something like this will break at a ton of > other places. > > I really wonder if it's worth supporting this, after all a lot of our > code checks getpid() == 1 to see if we are run in system mode. I mean, > once upon a time we had a mode in systemd, where we supported running > --system system as PID != 1. We removed that because it only ever > half-worked, because it confused things, because the usecase was > weak, because nobody really cared and because it bitrotted. Now, > supporting running systemd --user in a PID namespace kinda feels like > the same story, just inverted. Which makes me immediately wonder why > this should be different for this case. > > 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. User instances do and also avoid other undesired things like reading extra args from /proc/cmdline which isn't applicable to a container. 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. > > > Preventing exit from PID 1 makes sense when you're going to panic the > > kernel, but doesn't --user imply otherwise? > > Well, the --user switch as PID 1 is probably something we should > refuse early on... > > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel