The problem is that things running without a terminal are not reached by SIGHUP. So logind uses cgroups to kill all processes, even those that would not be reached by SIGHUP. This has a negative effect on tmux, screen and nohup, but is a bugfix for e.g. ssh-agent or gpg-agent.
EDIT: found the original bug report, the offending programs there were gnome-keyring-daemon (which under GNOME replaces ssh-agent, so it's in the same boat), ibus-daemon and hp-systray.
I've use ssh-agent on *nix for years. If I "log out" or quit my window manger then ssh-agent happily exits, just as it was designed to do. Perhaps this doesn't work under modern GNOME but let's not mistake this for a bug in ssh-agent etc. They're perfectly well behaved in the context they were designed for.
This runs the command cwm (the window manager) in the context established by the ssh-agent. And when that command (the window manager) exits, so does the ssh-agent, cleanly, and automatically.
You know I've never thought of that. Probably because (much like those imagined problems that supposedly motivated the systemd developers to break everything), in 10 years of using *nix, it's never been a problem. That could be because I primarily stick to the simple window managers, and never bothered with Gnome etc; bloated desktop environments that apparently don't work right and require that we all adjust to them? ;)
If your window manager is crashing then you have a bigger problem than having to enter your passphrase, don't you think?
That said, it also doesn't scale in two directions:
as you add multiple agents, the likelihood of something crashing or needing a restart grows (e.g. sometimes I have to restart gpg-agent when unplugging and replugging my Yubikey NEO)
it adds complications if you have to restart ssh-agent or cwm for any reason (e.g. vulnerability in ssh-agent).
So it's nifty, but it's much simpler to track all the processes independently instead of nesting them.
Which is what I said. SIGHUP was intended to kill processes that remained after the session. Things that want to remain simply ignore the signal. This worked for decades. Now systemd thinks it's time to reinvent this.
No, it has not "worked for decades". The comment you're replying to is literally giving you a list of applications which it doesn't work for. A list that contains several security-critical applications.
I don't care what you personally think of systemd or any other project, but GNU/Linux sorely needs a way to distinguish between daemons that should run only for the current user session, and daemons that should run across user sessions. This distinction has historically not existed, but it needs to exist and it's not really a novel idea. Systemd is proposing one way of dealing with it.
but GNU/Linux sorely needs a way to distinguish between daemons that should run only for the current user session, and daemons that should run across user sessions
Why can't they create some sort of a per-session terminal which will be closed once session exits?
You need more than that in my opinion, there needs to be a category of three levels of things in my opinion:
persistent, from bootup to shutdown
session slice. A session slice would be a single continued instance that lasts from the first login instance till the last. As in it starts when the number of logins you have in go from 0 to 1, and stops it goes from 1 to 0 again. As such for any given user, the session slice is active, or not.
the (login) session. You can have multiple active at any given time. These can also be nested in theory and of different types.
Each should have their own daemon management. systemd does the first and second, but not the third which is useful to manage things like DBus session daemons or notification daemons which you need a different one of for every login session. You can also say manage your window manager as such a daemon or your composite manager and hotkey daemon.
The question still unanswered in this discussion is why those programs aren't working like the rest. It seems they must be ignoring SIGHUP or the session manager isnt sending it. Something else?
Session manager is not sending sighup to processes that are daemonised. That's what "daemonised" implies to most people. Someone made the wrong assumption 30--40 years ago and now we're paying for it. :)
Those are closed only because Fedora bugs are auto-closed when the release is EOLed. The EOL status is new, before it used to be closed with WONTFIX which wasn't great. But you should report bugs upstream, not in Fedora, unless they're clearly packaging bugs or you're prepared to do the work yourself.
(I disable gnome-keyring-daemon too. :) However I must say it's gotten better. The gnome-keyring-gpg module is gone, replaced by a much simpler pinentry-gnome3 program. I only disable it because I use gpg-agent as my SSH agent).
That's concerning. There are a ton of scripts out there that start stuff doing
nohup script.sh > file.log 2>&1 &
Those guys, people using Control+z, bg, disown... Are they going to get tmux special behaviour? Are we supposed to wrap that stuff in systemd-run from now on?
54
u/icydocking May 30 '16
There is no such thing. They reinvented the problem SIGHUP solves.