Distributors ponder a systemd change
Distributors ponder a systemd change
Posted Jun 8, 2016 17:41 UTC (Wed) by drag (guest, #31333)In reply to: Distributors ponder a systemd change by ras
Parent article: Distributors ponder a systemd change
What if you consider a 'user session' to be system-wide instead of tied to a specific TTY?
I want to start processes that I can connect to and use regardless of how I log into a system, but when I am gone from the system completely I want them to be gone as well. Except in specific cases when I don't.
A example of this is Emacs.
Right now I use Emacs in 'daemon mode'. I would like to be able to connect and use it from different logins. I should be able to launch new client windows from another system over SSH and I would like to be able to use it from local login as well as X. When X dies I don't want it necessarily to be killed along with X if I happen to be using it from SSH for example.
But I also use Emacs for sensitive things. I have gpg-encrypted files that I open in Emacs for old passwords and things like that. So I _REALLY_ don't want Emacs sitting there running forever when I log out completely. It's far better for me to have to re-start emacs then have it sitting there with all my passwords decrypted in memory if I get forcefully disconnected from it.
I also want the behavior to be the same regardless how I happen to launch Emacs. If I launch it from a terminal emulator I want it's session behavior to be the same as if I launched it from ssh or from a X application menu.
> A PAM session management plugin would be the cleanest way to implement it.
How is a PAM session management plugin going to know which programs I want dead and which ones I don't?
Posted Jun 8, 2016 23:17 UTC (Wed)
by ras (subscriber, #33059)
[Link] (6 responses)
It can't easily know. (Easily being the operative word. It's just code, after all. It could say read ~/.kill-on-logout.lua, and use some function in there to decide.)
But I'm missing something here. How can any other solution easily know? Or perhaps you are focusing on the 1 -> 0 sessions trigger I gather the KillUserProcesses solution uses. If so, obviously the PAM plugin could use the same trick.
Sorry, I don't really understand your question.
Posted Jun 9, 2016 4:49 UTC (Thu)
by drag (guest, #31333)
[Link] (5 responses)
Well now I have the feeling that I was missing something.
You just tell systemd you want the process to live via the 'system-run --user' or launch the program via '--user' service file with a 'linger' option. But I suspect that is what the behavior is now for '--user' for 230 anyways. I'll need to play around with it I guess.
If it is true you can cause a process to linger just with a invocation of system-run or defining a service file, then my concerns/issues/questions are already all addressed.
Yeah, so I don't know.
When you can strip out most of the deamonization portions of a program and replace it with a simple <prognam>.service text file or wrapper shell script that calls 'system-run'.... and get superior results then was possible before I suspect that is the way to go rather then screwing around with pam, calls to dbus, or anything else. The simple solution is usually the better one.
I am starting to suspect that this is all just one huge non-issue as far as the technical issues are concerned, the problems are solved and the work needed by the developers is actually simplified. It's the social aspect of it that is the problem. People don't like to see change. I am not trying to downplay the issue, though. The social aspects are important.
Posted Jun 9, 2016 5:43 UTC (Thu)
by ras (subscriber, #33059)
[Link] (4 responses)
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
Distributors ponder a systemd change
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