Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
On Thu, 06.11.14 18:32, Michael Marineau (michael.marin...@coreos.com) wrote: 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. 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
--- src/core/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/main.c b/src/core/main.c index d48604e..cd9d6ee 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -2013,7 +2013,7 @@ finish: getpid() == 1 ? freezing : quitting); } -if (getpid() == 1) +if (arg_running_as != SYSTEMD_USER getpid() == 1) freeze(); return retval; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
On Thu, 06.11.14 14:44, Vito Caputo (vito.cap...@coreos.com) wrote: Hmm? What is this about? Why would you want to run systemd --user as PID 1? diff --git a/src/core/main.c b/src/core/main.c index d48604e..cd9d6ee 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -2013,7 +2013,7 @@ finish: getpid() == 1 ? freezing : quitting); } -if (getpid() == 1) +if (arg_running_as != SYSTEMD_USER getpid() == 1) freeze(); return retval; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
Imagine running systemd --user post-CLONE_NEWPID to manage services in the new namespace. Cheers, Vito Caputo On Thu, Nov 6, 2014 at 2:56 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 06.11.14 14:44, Vito Caputo (vito.cap...@coreos.com) wrote: Hmm? What is this about? Why would you want to run systemd --user as PID 1? diff --git a/src/core/main.c b/src/core/main.c index d48604e..cd9d6ee 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -2013,7 +2013,7 @@ finish: getpid() == 1 ? freezing : quitting); } -if (getpid() == 1) +if (arg_running_as != SYSTEMD_USER getpid() == 1) freeze(); return retval; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
On Thu, 06.11.14 16:26, Vito Caputo (vito.cap...@coreos.com) wrote: Imagine running systemd --user post-CLONE_NEWPID to manage services in the new namespace. But why not run it as --system then? Not following... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
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. Preventing exit from PID 1 makes sense when you're going to panic the kernel, but doesn't --user imply otherwise? Cheers, Vito Caputo On Thu, Nov 6, 2014 at 4:31 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 06.11.14 16:26, Vito Caputo (vito.cap...@coreos.com) wrote: Imagine running systemd --user post-CLONE_NEWPID to manage services in the new namespace. But why not run it as --system then? Not following... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
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? 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
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
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
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
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(). 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
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
