Distributors ponder a systemd change
Distributors ponder a systemd change
Posted Jun 9, 2016 5:43 UTC (Thu) by ras (subscriber, #33059)In reply to: Distributors ponder a systemd change by drag
Parent article: Distributors ponder a systemd change
Now I'm lost. The work required by developers under the old scenario was one of:
- None: if the user wants it to run after logout, he uses "nohup comand" or uses tmux or something.
- signal(SIGHUP, SIG_IGN)
How on earth could it get any easier than that?
Sure, it doesn't handle the emacs scenario you mentioned, but that seems to be pretty esoteric. It's very rare for me to have two logins on one machine, let alone a burning desire to share an editor session that I want killed when I log out of all sessions. Breaking backward compatibility, and adding all this complexity for the sake of something so specialised seems like a very odd design decision. It only gets odder when you know few lines of Python PAM module could do it.
Posted Jun 9, 2016 7:33 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
The scenario is dead simple - you logout, you log in and get two copies of a process that should exist in only one instance.
Posted Jun 10, 2016 0:57 UTC (Fri)
by ras (subscriber, #33059)
[Link]
> What if a user _does_ NOT want a process to survive a logout? Two scenario's: And so now you say but this is effecting a large cluster of machines the unwashed masses use - and they aren't going to do the kill. So the sysadmin that looks after them to interrupt his tea break on occasion - until the bug fix arrives. As a part time sysadmin myself, I have to concede this is indeed a very serious situation. Fortunately, there is a workaround. A short PAM module:
import os, signal, sys, time Job done! Well maybe. Comparing sessions works fine for ssh, but GNOME creates many of them now. To fix that the easiest kludge would be to kill all the user's processes when all of his sessions are gone. It would be hacky and racey - but this is just a kludge until the real bug fix comes in. It's a pity that's exactly what the real bug fix does.
Posted Jun 9, 2016 16:31 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
These sorts of command-control programs are becoming more common. Tmux is a example. Emacs is a example. But there are others. Gnome-terminal uses a terminal daemon to manage things. Urxvt has the ability to use Urxvtd to as well. With X they are limited to a particular login, but is that same limitation going to exist for Wayland? Is it going to be possible to run the program independent of the display and connect to it?
Then there is things like pulseaudio, mpd (music player daemon), irc bots, irc clients, IM bots, email weirdness, etc etc. These are programs you launch, you leave them floating around, and then connect to using a different process. In the future you'll start running into more AI stuff like Mycroft. Were you have 'helper' programs that the user interacts with, open source versions of Siri, 'hello google' or whatever.
They would all work just a bit better if they were tied to a user being logged into a machine, but not to a specific login.
What I think is going to happen is that we are running into a 'long tail' situation. Each of these things is esoteric, but there are a whole of people wanting to do their own esoteric thing.
At this point I really don't know. I'll have to play around with it.
Posted Jun 10, 2016 4:01 UTC (Fri)
by ras (subscriber, #33059)
[Link]
Lots of good questions. The answer to all of them is probably something along the lines of "session tracking is broken, lets fix it"
It's not like the problem of keeping something around only while there are references to it hasn't been stumbled over, cursed at and solved a million times already. The answer being proffered here is "session tracking is broken, so we're abandoning it".
That aside, rather than solving the issue at hand in a minimally intrusive way (may be by sending a SIGHUP to all processes owned by the user when his login session count drops to 0?), they pair it with "followed by an unconditional SIGKILL" because in their opinion they way we have been doing it for the last 30 years is wrong, and we need to be forced down their enlightened path.
If they had of decoupled the two, they probably would have got the first one through without much fuss and if the second one was a good idea it would have become the default in due course.
Distributors ponder a systemd change
Distributors ponder a systemd change
def pam_sm_open_session(pamh, flags, argv):
return pamh.PAM_SUCCESS
def might_fail(func, default=None):
try:
return func(*args)
except EnvironmentError:
return default
def session_pids():
my_pid = str(os.getpid())
get_proc = lambda pid, name: open("/proc/%s/%s" % (pid, name)).read()
my_session = get_proc(my_pid,"sessionid")
return (
int(pid) for pid in os.listdir("/proc")
if pid[0] >= '0' and pid[0] <= '9' and pid != my_pid
if might_fail(lamnda: get_proc(pid, "sessionid")) == my_session
if not "Z (zombie)" in might_fail(lambda: get_proc(pid, "status"), ""))
def kill_all(sig):
for pid in session_pids():
might_fail(lambda: os.kill(pid, sig))
def pam_sm_close_session(pamh, flags, argv):
kill_all(signal.SIGTERM)
for i in range(50):
if not any(session_pids()):
return pamh.PAM_SUCCESS
time.sleep(0.1)
kill_all(signal.SIGKILL)
return pamh.PAM_SUCCESSDistributors ponder a systemd change
Distributors ponder a systemd change