[systemd-devel] extra SIGTERM

[Lennart Poettering]

On Thu, 29.12.11 19:14, Michael D. Berger (m.d.berger at ieee.org) wrote:

> myDaemon.service:
> 
>    [Unit]
>    Description=myDaemon
>    After=syslog.target network.target
> 
>    [Service]
>    PIDFile=/var/lock/subsys/myDaemon
>    Type=simple
>    ControlGroup=cpu:/
>    ExecStart=/usr/sbin/myDaemon --daemon
>    #ExecStop=/bin/kill -s SIGTERM $MAINPID
> 
>    [Install]
>    WantedBy=multi-user.target
> 
> Using the service as shown, when I stop myDaemon,
> it gets one SIGTERM .
> 
> However, if I uncomment the ExecStop line, it gets
> two SIGTERMs in rapid succession.
> 
> Looks like a bug to me. What do you think?

How else should this behave? Note that sending SIGTERM with kill() is
asynchronous. So what happens is that your /bin/kill invocation enqueues
SIGTERM, and then systemd will kill what is remaining after that, also
with SIGTERM. Since there's no wait in between that means that two
SIGTERMs are sent one right after the other (since the kernel might
coalesce identical signals, if they aren't processed quickly you might
still see them as a single signal in times.)

What did you expect instead?

Note that you can influence which signal is sent by systemd, and to
which processes: with KillMode= and KillSignal=. You can also control
whether a final SIGKILL shall be sent as last fallback if the service
doesn't react to SIGTERM within a timeout. You can even turn off all
sending of signals by systemd, with SendSIGKILL=no and KillMode=none.

Or in other word: explicitly invoking /bin/kill in ExecStop= is almost
always entirely redundant.

So, as far as I can see everything behaves as it should?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.