[systemd-devel] ExecReload-spawned process getting SIGKILLed

Dave Reisner d at falconindy.com
Thu Jun 7 05:54:33 PDT 2012


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?
> 



More information about the systemd-devel mailing list