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 10:39 UTC (Sun) by cortana (subscriber, #24596)
In reply to: Changes coming for systemd and control groups by zblaxell
Parent article: Changes coming for systemd and control groups

Why don't the following options work for you?


Configures the time to wait for start-up and stop. If a daemon service does not signal start-up completion within the configured time the service will be considered failed and be shut down again. If a service is asked to stop but does not terminate in the specified time it will be terminated forcibly via SIGTERM, and after another delay of this time with SIGKILL. (See KillMode= below.) Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass 0 to disable the timeout logic.

Defaults to 90s.


Specifies how processes of this service shall be killed. One of control-group, process, none.

If set to control-group all remaining processes in the control group of this service will be terminated on service stop, after the stop command (as configured with ExecStop=) is executed. If set to process only the main process itself is killed. If set to none no process is killed. In this case only the stop command will be executed on service stop, but no process be killed otherwise. Processes remaining alive after stop are left in their control group and the control group continues to exist after stop unless it is empty. Defaults to control-group.

Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=). If then after a delay (configured via the TimeoutSec= option) processes still remain, the termination request is repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option). See kill(2) for more information.


Specifies which signal to use when killing a service. Defaults to SIGTERM.


Specifies whether to send SIGKILL to remaining processes after a timeout, if the normal shutdown procedure left processes of the service around. Takes a boolean value. Defaults to "yes".

Emphasis is mine. These are taken from the systemd.service man page.

(Log in to post comments)

Changes coming for systemd and control groups

Posted Jun 25, 2013 19:43 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. SIGTERM-wait-then-SIGKILL is completely standard in Unix shutdown scripts. I'm not sure I've ever seen one that doesn't do that, and systemd can too.

Changes coming for systemd and control groups

Posted Jul 2, 2013 20:54 UTC (Tue) by zblaxell (subscriber, #26385) [Link]

Traditional Unix shutdown scripts send these signals once, when the entire system is about to be (forcibly) rebooted, and it no longer matters what processes are still running because the kernel is going to stop soon anyway.

Individual init.d-style scripts might send signals to specific processes, but that's usually ad-hoc behavior that makes sense for each daemon (i.e. Apache or Postgres send signals to all their children, while sshd only signals the master process and leaves child sessions alone). While I appreciate that it might be useful to refactor to a single implementation, it makes no sense for that single implementation to do something new and surprising by default.

systemd sends SIGKILL in many new situations, such as when a login session ends, or a service is restarted, or a TCP connection is lost. None of these imply even SIGTERM, let alone SIGKILL, and certainly not for processes that are many generations removed from the initial service process.

Changes coming for systemd and control groups

Posted Jul 18, 2013 12:30 UTC (Thu) by nix (subscriber, #2304) [Link]

Good grief! Agreed! (Heck, I *rely* on some things surviving logout. Looks like systemd is out, for me...)

Changes coming for systemd and control groups

Posted Jul 18, 2013 15:07 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

So just use appropriate tools for this. What's the problem?

Changes coming for systemd and control groups

Posted Jul 18, 2013 19:28 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

My tmux and pulseaudio session survive a logout with systemd-logind just fine. However, when I move over to systemd --user, I'll need to find a different way to keep tmux alive since that *does* kill all children sessions by default. It seems to involve something with tmux making a PAM session and upstream has already expressed that it's not something they're thrilled about, but I also haven't gotten it to fully work (screen would need to do a similar thing).

Why would I want to move over? The biggest benefit I see is that I can set session-wide environment variables and have new programs inherit them. To do this with startx, I would need to inject variables into either XMonad's environment to modify new programs (which is not where it belongs), launch from a shell, or launch everything from some trampoline program.

Changes coming for systemd and control groups

Posted Jul 18, 2013 21:10 UTC (Thu) by nix (subscriber, #2304) [Link]

I must say I've had no trouble injecting env vars into fvwm's parent via .Xinitrc for, well, ever. And I can't imagine it ever not working with any other window manager, either. (Of course, not all provide a nifty thing like FvwmCommand to adjust the wm's state, and thus set of env vars, while it's running, but I find it hard to believe that XMonad can't do that.)

Changes coming for systemd and control groups

Posted Jul 18, 2013 21:38 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Yeah, I can set envvars at the start of the session, but I can't modify/remove/add any afterwards. XMonad *can* do it, but again, that's not the place to do it (IMO). Things like restarting ssh-agent should automatically refresh the system's environment for new applications automatically which systemd --user can give me for free via a keychain@ssh.service while I'd have to manually tell XMonad about it otherwise.

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