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

Changes coming for systemd and control groups

Changes coming for systemd and control groups

Posted Jul 2, 2013 20:54 UTC (Tue) by zblaxell (subscriber, #26385)
In reply to: Changes coming for systemd and control groups by nix
Parent article: Changes coming for systemd and control groups

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.


(Log in to post comments)

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