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.

Attachment: pgpzzPzIFip6x.pgp
Description: PGP signature

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to