User: Password:
|
|
Subscribe / Log in / New account

Changes coming for systemd and control groups

Changes coming for systemd and control groups

Posted Jun 23, 2013 2:46 UTC (Sun) by zuki (subscriber, #41808)
In reply to: Changes coming for systemd and control groups by zblaxell
Parent article: Changes coming for systemd and control groups

> The data loss occurs because systemd will send SIGKILL to all processes in cgroups it knows of by default.

What is sent to the process can be arbitrarily configured with ExecStop. E.g. ExecStop=/bin/kill -USR3 will cause your unit to be stopped with USR3 signal. Not that it makes any sense, but if you insist. Also, TimeoutStopSec= can be used to give the service as much time as it needs.
As for "data loss", well, you can't have both predictable stopping of processes, and allow them to take indefinite time to stop. You *can* disable the timeout with TimeoutStopSec=0, but this means that one service can hang a reboot or shutdown. I can image that it is useful in certain scenarios, but definitely it doesn't make sense as a default setting.

> the onus is clearly on systemd to support legacy programs well, not on every legacy program to learn how to beg a process that didn't exist until 20 years after they were written to not kill them.
Systemd unit files also didn't exist 20 years ago. When you'll be writing one to support the dinosaur program, you can add one or two configuration lines which will tweak the service stop mechanism.


(Log in to post comments)

Changes coming for systemd and control groups

Posted Jun 23, 2013 3:34 UTC (Sun) by Tobu (subscriber, #24111) [Link]

AIUI, to get away from the default behavior one needs to either patch systemd or set `SendSIGKILL=no` for every unit known to systemd.

Changes coming for systemd and control groups

Posted Jun 23, 2013 14:50 UTC (Sun) by zuki (subscriber, #41808) [Link]

> AIUI, to get away from the default behavior one needs to either patch systemd or set `SendSIGKILL=no` for every unit known to systemd.
Yes. What I'm saying, is that this is something that makes sense only for very special units, not as a default. Actually, for the majority of services and other units, ability to cleanly kill all children is a blessing.

Changes coming for systemd and control groups

Posted Jun 23, 2013 15:17 UTC (Sun) by Tobu (subscriber, #24111) [Link]

To interoperate properly with systemd, zblaxell's resource partitioning would need to tweak all existing unit files, or put the entire process tree under a single unit, or fork systemd, all non-trivial hacks that hamper work on what should be an orthogonal concern. And that just deals with the kill signals, it doesn't help with the single-cgroup-hierarchy change that will either break his program or break systemd, depending on mount flags.

I can understand his pain, it's an all-or-nothing choice. Either systemd does everything everyone needs (over a rather enormous functional area), or you have an uphill fight to regain enough control to do it your way.

Changes coming for systemd and control groups

Posted Jun 23, 2013 19:42 UTC (Sun) by raven667 (subscriber, #5198) [Link]

I'm not exactly sure what zblaxell is doing with cgroups but I can understand that having systemd create and manage cgroups for services could conflict with whatever custom use case they have. If we better understoond what the goal was then maybe we could find a different way to do it that doesn't conflict.

Changes coming for systemd and control groups

Posted Jun 23, 2013 10:48 UTC (Sun) by cortana (subscriber, #24596) [Link]

I think using ExecStop in that way will result in SIGUSR3 followed immediately by SIGTERM (then a delay, then SIGKILL).

You can say KillSignal=SIGUSR3 to have SIGUSR3 sent instead of SIGTERM, rather than having both sent.

You can also set KillMode=none instead of setting TimeoutStopSec=0. That should prevent the infinite hang when the system is shutting down (since the timeout will be of finite duration, but it won't be followed by SIGKILL).

Changes coming for systemd and control groups

Posted Jun 23, 2013 15:15 UTC (Sun) by zuki (subscriber, #41808) [Link]

> I think using ExecStop in that way will result in SIGUSR3 followed immediately by SIGTERM (then a delay, then SIGKILL).
You're right. This behaviour is logical, but I find it surprising every time. Other comments link to RH bugzilla #952634, and additional options to tweak this further will be added.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds