Re: [systemd-devel] ExecReload-spawned process getting SIGKILLed
On Thu, 07.06.12 19:36, Sam Varshavchik (mr...@courier-mta.com) wrote: Dave Reisner writes: On Thu, Jun 07, 2012 at 08:41:54AM -0400, Sam Varshavchik wrote: This is wrong. ExecReload should not cause the process to change PIDs. Not that this was ever allowed, but the below commit is was causes the SIGKILL behavior you're seeing: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8f53a7b8ea9b Thanks for confirming that this SIGKILL comes from systemd. This, however, blocks re-exec()ing of a secure, non-root daemon that runs in a chroot jail. The workaround that's needed to work around this obstacle, is messy. It appears to me that you your reload shouldn't be called reload. I mean, if you just sop and restart your service, then we already have that, it's called restart, and is implemented implicitly for you. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecReload-spawned process getting SIGKILLed
Lennart Poettering writes: On Thu, 07.06.12 19:36, Sam Varshavchik (mr...@courier-mta.com) wrote: Dave Reisner writes: On Thu, Jun 07, 2012 at 08:41:54AM -0400, Sam Varshavchik wrote: This is wrong. ExecReload should not cause the process to change PIDs. Not that this was ever allowed, but the below commit is was causes the SIGKILL behavior you're seeing: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8f53a7b8ea9b Thanks for confirming that this SIGKILL comes from systemd. This, however, blocks re-exec()ing of a secure, non-root daemon that runs in a chroot jail. The workaround that's needed to work around this obstacle, is messy. It appears to me that you your reload shouldn't be called reload. I mean, if you just sop and restart your service, then we already have that, it's called restart, and is implemented implicitly for you. Your restart in insufficient to implement a reexec. This is not a restart. This is a reexec, and a chrooted daemon cannot reexec itself, of course. The new binary isn't even accessible from the existing daemon's chroot jail. This must be done using an internal state transfer to the new daemon from the existing one, which then terminates. The new daemon chroot-s itself back where the terminated daemon was running from. The new daemon must, therefore, be either the process that's started by systemd or one of its child processes. Furthermore, I see no documentation of ExecRestart. As far as I can tell, systemd restart is just an ExecStart after an ExecStop (if the service is already running). Which, of course, is not the same thing. Only a reload-or- try-restart has the correct semantics for a reexec after a package upgrade. But with systemd now sigkilling the replacement daemon process, this is no longer possible, without more work. pgpzzPzIFip6x.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ExecReload-spawned process getting SIGKILLed
After going from F16 to F17, going from systemd 37 to systemd 44, seemingly, my ExecReload broke. Using strace, my process is getting SIGKILLed. I suspect this is systemd's doing, and I would like to confirm my suspicions. The service file has Type=Forking and RemainAfterExit=true. The process invoked by ExecStart forks, the parent terminates, the child continues to run. The same is true for ExecReload. The process invoked by ExecReload forks, and the parent terminates. The child process makes the necessary arrangement to contact the current background process, transfer the internal application state to the new process, then the original process terminates, with the child taking its place. My strace shows that the new background process gets SIGKILLed shortly thereafter. Without any other theories, I'm just guessing that systemd expects that every process started by ExecReload should terminate, and will SIGKILL any stragglers, and that doesn't work for me. Assuming that my guess is true, and that ExecReload's behavior in systemd has changed, how should I configure something like this, then, for ExecReload to spawn off a child process to take the existing child process's place? pgpyRIkS5liWe.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecReload-spawned process getting SIGKILLed
Sam Varshavchik writes: Assuming that my guess is true, and that ExecReload's behavior in systemd has changed, how should I configure something like this, then, for ExecReload to spawn off a child process to take the existing child process's place? One last detail I forgot. The background processes are running in a chroot jail. It's not possible for the existing background process to fork, and reexec. pgpwmxDDlWqIS.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecReload-spawned process getting SIGKILLed
On Thu, Jun 07, 2012 at 08:41:54AM -0400, Sam Varshavchik wrote: After going from F16 to F17, going from systemd 37 to systemd 44, seemingly, my ExecReload broke. Using strace, my process is getting SIGKILLed. I suspect this is systemd's doing, and I would like to confirm my suspicions. The service file has Type=Forking and RemainAfterExit=true. This seems wrong. RemainAfterExit is usually meant to apply to Type=oneshot units which apply a change in state, such as static network configuration. The process invoked by ExecStart forks, the parent terminates, the child continues to run. So the MAINPID of this unit would be the child. You should be writing a PIDFile from the child that systemd can explicitly track. The same is true for ExecReload. The process invoked by ExecReload forks, and the parent terminates. The child process makes the necessary arrangement to contact the current background process, transfer the internal application state to the new process, then the original process terminates, with the child taking its place. This is wrong. ExecReload should not cause the process to change PIDs. Not that this was ever allowed, but the below commit is was causes the SIGKILL behavior you're seeing: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8f53a7b8ea9b My strace shows that the new background process gets SIGKILLed shortly thereafter. Without any other theories, I'm just guessing that systemd expects that every process started by ExecReload should terminate, and will SIGKILL any stragglers, and that doesn't work for me. Your assumption about ExecReload is incorrect. It's intended to do things like re-read config files, or re-open file descriptors. Assuming that my guess is true, and that ExecReload's behavior in systemd has changed, how should I configure something like this, then, for ExecReload to spawn off a child process to take the existing child process's place? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecReload-spawned process getting SIGKILLed
On 06/07/2012 12:41 PM, Sam Varshavchik wrote: The service file has Type=Forking and RemainAfterExit=true. Hmm which unit file is this? You dont use RemainAfterExit=true with Type=forking JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecReload-spawned process getting SIGKILLed
Dave Reisner writes: On Thu, Jun 07, 2012 at 08:41:54AM -0400, Sam Varshavchik wrote: This is wrong. ExecReload should not cause the process to change PIDs. Not that this was ever allowed, but the below commit is was causes the SIGKILL behavior you're seeing: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8f53a7b8ea9b Thanks for confirming that this SIGKILL comes from systemd. This, however, blocks re-exec()ing of a secure, non-root daemon that runs in a chroot jail. The workaround that's needed to work around this obstacle, is messy. pgpWoLLwcmo0r.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
