SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
Posted Jun 10, 2016 8:55 UTC (Fri) by matthias (subscriber, #94967)In reply to: SIGHUP for "session has gone away", not SIGTERM/SIGKILL by ras
Parent article: Distributors ponder a systemd change
> Obviously it's a kludge. It's racy (what if a person is logs between the 0->1 test and you lot starting to kill processes),
In contrast to solutions with pkill, systemd should only kill processes belonging to closed sessions (and not of the new session), as it tracks sessions with cgroups. There might be a race condition if the new session decides to use some process of an old session which gets killed. I am not sure whether systemd removes this race by delaying the start of the new session while on a killing spree. This should be possible.
> and it won't always work (what about processes started as a different user),
I just tested this starting some process with su as a different user (I temporarily added my test user to the wheel group). The process was terminated, because it was in the same cgroup. This case should not be that important anyway, as normal users are not allowed to start processes as different users.
> and it isn't backward compatible with what worked for 30 years now.
I agree, but the programs that need changes are very few. For most cases, background processes are started as daemons anyway. I always see screen and tmux mentioned and their session management is broken anyway. Helper programs like ssh-agent get terminated when the user logouts, even when they are needed inside the screen. Registering a session with PAM would be cleaner anyway.
Obviously this change should only hit stable distributions, once screen and tmux are fixed (either upstream or by distribution patches).
Posted Jun 11, 2016 0:30 UTC (Sat)
by ras (subscriber, #33059)
[Link] (7 responses)
Yes, I can well imagine it would be.
But you did have another option: http://lwn.net/Articles/690555/
Well maybe not that precisely, but with a few tweaks you could have made it kill all processes owned by a student when his last session was gone, and unlike the current proposal made it very selective so only the students were effected and not sysadmins or others squawking here. This is exactly the sort of problem PAM's session management is well suited to.
Posted Jun 11, 2016 2:06 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Jun 11, 2016 8:42 UTC (Sat)
by ras (subscriber, #33059)
[Link] (5 responses)
It was just a work-around, and I don't doubt there are many people who think getting upstream to provide a config option for their particular problem is a better solution. Maybe you are one of them. I'm not.
There is a 50 line solution to the problem. It isn't a patch to upstream I have to carry, the API is stable, a compile isn't required, it doesn't require me to monitor upstream security problems and rebuild it with every fix - it's just drop a file into a directory and go. If I was the sysadmin being given grief by miscreant students, I know I would have invested the hour needed to write it. If as claimed there are lot of other sysadmin's with the same problem, I am somewhat puzzled that it isn't packaged and available on the major distro's already, because if it had been it would have been just a setting in PAM's config file.
Which brings us to the real point. I don't use Linux because it has a setting in a config file for my every need - that's an impossible ask after all. (If I believed it was possible, I would be using Windows. Obviously it's not there yet, but given it's possible it must be just around the corner ...) I use 'nix because it's swiss army knife that is so flexible, in for most problems there is a 50 line solution.
The KillUserProcesses setting looks nothing like that. Elsewhere you said it can be controlled per user. What if I don't think per user particularly useful? Maybe I'm a sysadmin with miscreant student population in a large educational institution that turns over staff regularly, and with every change of staff I have to change the systemd configuration on 100's of machines. I don't think so. Give me a system that provides the flexibility to configure in a way that suits me. Maybe I put all students in the one group, or maybe I lookup payroll, or read a flag out of FreeIPA.
I'd take that over flexibility over a specialised "config option" any day. Quite apart from anything else, I could not be as productive in my profession life without it.
Posted Jun 11, 2016 11:25 UTC (Sat)
by pizza (subscriber, #46)
[Link] (4 responses)
Then it's a good thing that you're not forced to choose between those two, eh?
Posted Jun 11, 2016 11:55 UTC (Sat)
by ras (subscriber, #33059)
[Link] (3 responses)
If we could leave it turned off with no repercussions other than our tmux sessions continue to run, there wouldn't be almost 300 posts on LWN about this. The reality is, if we want GNOME to clean up properly, we have to enable KillUserProcesses. Frankly I'd even accept that, albeit for purely selfish reasons as I'm not a fan of GNOME 3. Unfortunately many of the other window managers rely on GNOME to fill the gaps in their own efforts, including the one I use on my laptop.
This doesn't feel like we are being offered a choice.
Posted Jun 11, 2016 14:55 UTC (Sat)
by pizza (subscriber, #46)
[Link]
You are, in a word, incorrect.
Posted Jun 12, 2016 10:20 UTC (Sun)
by micka (subscriber, #38720)
[Link] (1 responses)
Slowly reading through them. From what I've read up until now two thirds are from 3 or 4 persons. I'm not sure what you can deduce from the number of comments except that there are very talkative commenters.
Posted Jun 17, 2016 16:01 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Certain topics press certain buttons. Gnome brings out one set of posters.Systemd brings out another (and I've noticed systemd tends to attract troll accounts I've never seen before ...)
And databases? Well that tends to get me going :-) It's all about what matters to people. And some people just enjoy sitting in the peanut gallery lobbing rotten tomatoes ... :-)
Cheers,
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
SIGHUP for "session has gone away", not SIGTERM/SIGKILL
Wol