On Thu, 29.12.11 19:14, Michael D. Berger (m.d.ber...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
