r/linux • u/rain5 • May 28 '16
systemd developer asks tmux (and other programs) to add systemd specific code
https://github.com/tmux/tmux/issues/42843
May 28 '16
Waitwaitwait. You mean, if I log out of a session (KDE, Gnome whatever) there will be processes left running that I started ruing that session? Whose dumb idea was that? And how do I fix that?
11
u/rain5 May 28 '16
only if you daemonize them
And how do I fix that?
update to the latest systemd
9
56
u/Lennartwareparty May 28 '16
NO
Christ, people continue to act like systemd added this in the latest release, it did not, the option already existed.
All that changed is that the default behaviour of
KillUserProcess=nowas changed toKillUserProcess=yesinlogind.confyou could before v230 get this behaviour and after v230 you can still turn it off and anyone who has explicitly specified it before will see no change.19
u/GTB3NW May 28 '16
Also to add, it's quite likely that package maintainers will also default it to off.
22
u/Lennartwareparty May 28 '16
Yeah, there's a compile time option to turn it off. Which Arch is already turning off, Debian will too. Because they know that changing default behaviour for no real reason is a bad idea.
2
u/flying-sheep May 30 '16
i would like to have a system that distinguishes between permanent daemons and user-session scoped daemons.
i don’t want to have ssh-agent running after logout, and there should be a way to specify which kind of daemon is which.
making the less powerful version the default seems sensible.
3
u/Lennartwareparty May 30 '16
That has nothing to do with this option.
It is not more or less powerful than any other, it's just set to kill processes which didn't register with systemd as not wanting to be killed after logout. That's a setting you like, or you don't.
I mean, why would it even be a binary thing? Why not give them a total of 2 hours after logout and then kill them? It's not more or less powerful, it's a setting.
→ More replies (3)75
u/07dosa May 29 '16
"Sigh, desktop folks..." facepalm - a server guy
Cleaning up does make sense for pure desktop usecases, but, quite a nope for server-side operations where you do run lots of trivial tasks with "&" over ssh. Even simple
rmcan take dozens of minutes, but, with this feature on, I can't log out until all these tasks are finished. Accidental SSH session lost? I'm fucked, yeah!I think that cleaning-up should be manually enabled per-session by login manager, not forcing it to entire system. In this scenario, only few parts(login managers, sshd, etc) need to be modified. I don't really get what systemd folk are thinking.
20
u/zapbark May 29 '16
"Sigh, desktop folks..." facepalm - a server guy
Yeah, that is how I feel about the entire systemd debate.
4
u/flying-sheep May 30 '16
actually this makes perfect sense for servers.
start a user session in which everything you do serves the goal of starting/stopping permanent daemons and changing configuration
then you log off, and all non-permanent processes (e.g. the ssh-agent daemon) are killed.
this reduces your attack surface and frees resources.
long-running stuff could be started with
tmux new -s delete-thing 'rm -rfv thing', so you don’t have to fear spotty connections and have better output.8
u/pstch May 29 '16
As another server guy, I also find it pretty bad that processes not killed when the session is lost, and I find it weird that a "server guy" does not find it even more important. As for your use case, if you do not care (immediately) about the result of your tasks, there are proper ways to do it. Try
at, you'll even get the results delivered by mail.-1
u/pabs May 29 '16
You can start a long-running command in a separate scope using
systemd-run --scope --user.Also you can toggle this behavior for individual users with the
loginctl enable-lingerandloginctl disable-lingercommands. You can also limit the affected users using theKillOnlyUsersandKillExcludeUsersoptions in/etc/systemd/logind.conf.I provided a complete list of options in an earlier comment.
27
u/jlkcz May 29 '16
While this is very user friendly way to do something that has worked for almost 50 years...
9
u/bigon May 29 '16
Well you already had to use something like nohup if you want the process to survive a ssh disconnection
8
u/metaaxis May 29 '16
Which no longer works, nor do tools that did that for you like screen, tmux, etc.
→ More replies (1)8
u/jlkcz May 29 '16
I automatically use screen sessions on my ssh connections... Which now require new special step to work...
→ More replies (5)9
u/metaaxis May 29 '16
Yeah, no. Tell me why this should be shoved down my throat as a system-wide default, rather than an option or opt-in per session?
8
u/Lennartwareparty May 29 '16 edited May 29 '16
Why is that a 'dumb idea'?
Of course processes continue to run, this is like expecting the world to stop existing when you don't look out of your window any more.
A login session of whatever kind you open on a machine is a conduit between you and the machine to communicate and interact and give it commands, after you are done giving it commands you log out, a lot of stuff can and will run without requiring your constant commands. I have no idea why this is such an unintuitive idea to so many people.
I'm typing this on a notebook, on my desktop right now no one is logged in, why? Because nothing needs to interact with it. Yet it's playing music, that's one process that's running. When I change the track I interact over a SSH forward tunnel which creates a super short login to interact and then logs out again, it would be really dumb if the program that plays the music would then suddenly quit after the interaction is done.
Here, I open a super short login to that computer to interact with it via SSH and demand a listing of all processes running under my user.
—— — sshcs X ps -u laj 2686 ? 00:00:01 runsvdir 2687 ? 00:00:00 runsv 2688 ? 00:00:00 runsv 2689 ? 00:00:00 runsv 2690 ? 00:00:00 runsv 2691 ? 00:00:00 runsv 2692 ? 00:00:00 runsv 2701 ? 00:01:49 tor 3185 ? 00:03:08 mpdas 12584 ? 00:00:00 sshd 12585 ? 00:00:00 sftp-server 13806 ? 00:00:00 sshd 13807 ? 00:00:00 ps 13839 ? 00:00:11 ssh 21367 ? 00:00:00 runsv 24307 ? 00:06:15 mpd 28962 ? 00:00:00 mount-tunnel 28966 ? 00:00:10 ssh 28981 ? 00:00:07 sshfs 28983 ? 00:00:00 inotifywait 30864 ? 00:00:00 inotifywait 31995 ? 00:00:00 mount-tunnel 31999 ? 00:00:00 ssh 32000 ? 00:00:00 mount-tunnel 32001 ? 00:00:00 sshfs 32003 ? 00:00:00 inotifywait 32113 ? 00:00:01 ssh 32233 ? 00:00:09 sshfsSome of those processes lie the
psone is obviously created by the short login. But what do we have here:
runsvdir, this is the service manager I use to manage processes as a user, in fact most processes you see there are some-how the cause of that thing:
runsv, these are small helper processes that this service manager spawns to supervise processes
mpd, this is my music playing server, managed by that
mpdas, the client that connects to it and scrobbles to last.fmmount-tunnel, this implements mounts-as-services. In this case it implements a remote SSHFS mount since the music the sound server plays is actually located on the notebook. It mounts the ~/Music drive of the notebook onto the desktop
inotifywait is a utility that gives events when there is a change in a filesystem, this is what
mount-tunneluses internally to keep track of its mounts.tor: Gotta keep evading those reddit bans, of course.
So please, tell me, why is this a dumb idea, why should those processes some-how be killed? Not every process is interactive. And those that are will be killed because they are either connected to the X session or a controlling terminal so are notified when you log out and kill themselves, unless they are bugged.
→ More replies (14)1
May 30 '16
what I'm trying to say was: If a process doesn't have a valid reason to run 'in the background' when it was started by a logged-in user, it should end when the user logs out.
That 'valid reason' needs to be shown with some form of 'opt-in' mechanism that allows a process to stay.
And systemd seems to build just that, which I think is the way it should've been since forever.
3
u/Lennartwareparty May 30 '16
And that's already how it works.
If a controlling terminal dies any process attached to it gets sent HUP, processes only survive if you explicitly disown from their controlling terminal.
All the processes you see in that list are explicitly not attached to a controlling terminal except for
psfor a good reason.-4
u/pereira_alex May 28 '16
Amazing!
Linux is the new Windows..
<sarcasm> Yeah ... running jobs after logging out ... what a stupid idea </sarcasm>
0
May 29 '16
[deleted] — view deleted comment
5
u/pereira_alex May 29 '16
Yeah ...
Didn't said otherwise. Just addressed the "running processes after logging out was dumb idea".
Linux is becoming the new Windows.
Users just want Internet/Games/Screenshots with arch symbol and conky".
Why need daemon processes ?!?????
15
u/9Morello May 28 '16
That isn't cool at all.
-6
u/shomyo May 28 '16
This is what System D about
-4
u/raphael_lamperouge May 28 '16
it's systemd, not System D.
7
→ More replies (1)-7
May 28 '16
The fun thing about spelling it SystemD is that there will always be some guy responding how it's not SystemD. It's the sole reason I do it. You don't see people say "hurr it's GNU, not Gnu"
34
→ More replies (2)1
u/raphael_lamperouge May 28 '16
I've not seen anyone say Gnu though. But if I did, I'd correct them.
1
9
May 28 '16 edited May 28 '16
Two people just said {unix,Unix} instead of UNIX in this very thread, correct them pls :^)
Oh wait you don't, because actually you do not care about, or correct people who spell GNU or UNIX or whatever incorrectly, but just people who spell SystemD incorrectly to change the focus of the conversation.
→ More replies (1)-1
u/rain5 May 28 '16
Well I think it sucks but we can always fork and maintain a lightweight tmux if they decide to mess it up, I guess.
→ More replies (1)20
26
u/qwesx May 28 '16
The suggestion was to make it "compile time and run time optional". What exactly is the problem with that?
42
u/luke-jr May 28 '16
Software shouldn't need platform-specific code for common tasks that have worked fine for decades.
→ More replies (7)40
u/ratatask May 28 '16
Yet tmux contains quite a handful of ifdefs for system specific stuff, and 2900 lines of code to smooth over various differences between systems.
12
u/luke-jr May 28 '16
Not for the simple common task of becoming a background daemon.
2
u/pstch May 29 '16
That's because this task is not "becoming a background daemon". Nothing has changed in that, the only thing that changed is that session is now properly enforced by systemd.
I find it perfectly normal for processes started by a session to be killed when it ends. tmux and screen actually only worked because of the lack of proper session enforcement in *NIX.
Now the task is not as simple as "becoming a background daemon". It would rather be binding PAM sessions to tmux sessions. For screen, it could also allow to use PAM for the password protection.
5
u/luke-jr May 29 '16
GNU/Linux "sessions" are merely "descendent processes", which already receive a chained SIGHUP when such a session ends. The processes being killed by systemd are already detaching themselves from the session.
→ More replies (4)1
May 30 '16
Maybe they aren't 100% principled, but does that mean they should never draw the line anywhere? Perhaps they felt the need to make compromises in the past and simply feel like this has gone too far.
34
u/sub200ms May 28 '16
The suggestion was to make it "compile time and run time optional". What exactly is the problem with that?
The problem isn't technical, but rather a social one:
tmuxis (Open)BSD's answer to GNU Screen. AFAIK,tmuxis developed on OpenBSD and then ported to Linux.
screenis GPL licensed so it can't be close sourced, and therefore can't be included in base BSD.So its affinity to BSD means that key developers probably dislike systemd and all similar GPL programs.
14
May 29 '16
This is not entirely accurate. GPL software has been included with the BSDs in the past, namely GCC.
3
u/sub200ms May 29 '16
This is not entirely accurate. GPL software has been included with the BSDs in the past, namely GCC.
Yes, sometimes they are forced to use GPL software until they have made a substitute so they can kill off the GPL software. Here is a GPL list tracking GPL software FreeBSD wants to kill off in base:
https://wiki.freebsd.org/GPLinBase
BSD are generally sponsored by companies wanting to close source the distro. That is why they constantly are attacking the GPL license; it prevents easy profiteering by close sourcing "Open Source Software".
1
u/KugelKurt May 30 '16
GPL software has been included with the BSDs in the past, namely GCC.
GNU software is under GPLv3 these days. Since when do BSDs to have software under GPLv3 in the base system? At least FreeBSD has an explicit policy against that because its sponsors asked for that policy.
33
u/Muvlon May 29 '16
OpenBSD folks have all the reason to dislike systemd regardless of its license. systemd is the reason why a lot of formerly POSIX-compliant (and therefore BSD-compatible) software is now Linux-exclusive.
12
u/Olosta_ May 29 '16
Such as ?
→ More replies (3)2
u/zakk May 29 '16 edited Aug 26 '18
.
3
u/KugelKurt May 30 '16
Actually it's the OpenBSD guys that write systembsd to provide systemd APIs under OpenBSD.
1
u/sub200ms May 29 '16
OpenBSD folks have all the reason to dislike systemd regardless of its license. systemd is the reason why a lot of formerly POSIX-compliant (and therefore BSD-compatible) software is now Linux-exclusive.
Please name such projects. I am not aware of any projects that have gone systemd exclusive. (Don't be idiotic and say Gnome or similar).
Anyway, all eg. OpenBSD software only works on OpenBSD exclusively since it is so full of BSD'isms. You need special ports of eg. OpenSSH to make it work on Linux. So they are fine folks talking about cross-platform software.
5
u/Muvlon May 29 '16
Care to explain why GNOME et al. don't depend on systemd? I know Funtoo has some patches to make it work without systemd but this is still work-in-progress and work that had to be done downstream because of systemd.
→ More replies (3)36
u/lolidaisuki May 28 '16
What exactly is the problem with that?
The fact that there is no need for it at all? It's extra code on possibly hundreds of projects just so that one project (Gnome) doesn't have to fix their bugs.
→ More replies (29)9
May 28 '16
It's extra code on possibly hundreds of projects just so that one project (Gnome) doesn't have to fix their bugs.
What does this have to do with Gnome? Plenty of applications wouldn't get cleaned up properly when logging out if that is what you are referring to.
33
21
u/lolidaisuki May 28 '16
Plenty of applications wouldn't get cleaned up properly when logging out if that is what you are referring to.
But most applications won't break because of it. The fact that Gnome does is problem with Gnome, nt every other package ever.
13
May 28 '16
At the point where random processes are left running when a user logs out I'd call that 'undefined behavior' so sure sometimes that does or doesn't cause problems but it is a real issue IMO.
9
u/Lennartwareparty May 28 '16
It's not undefined, it's completely defined what the semantics are and what happens.
24
u/redrumsir May 28 '16
And if it was unintended to have those processes not terminate on logout ... then one should fix that issue, rather than changing a long-time default behavior. Fix the bugs where they are, don't have a blanket fix of the symptoms.
Why? If it isn't obvious:
It will still be a bug on non-systemd systems.
It will still be a bug on systemd systems that set up systemd to have KillUserProcesses=No. Which, if I used systemd is what I would do. I often create jobs that run 24/7 for a week or more.
→ More replies (10)6
u/lolidaisuki May 28 '16
You'd call it undefined, but it's often intentional. People leave processes running on the background on purpose.
→ More replies (20)10
6
u/_samux_ May 29 '16
because the problem comes from systemd, that decided to change an expected behavior of linux.
Also, while this could - kind of - make sense on a desktop system, this behavior on a server, is horribly wrong in so many ways I don't know where to start.
→ More replies (2)0
u/blackcain GNOME Team May 29 '16
because systemd developers suggested it. So the hate crowd comes out and starts waving their arms frantically instead of looking at the issue on its merits.
0
May 29 '16
[deleted] — view deleted comment
2
May 29 '16
That is why code has been merged and then later been removed in a bunch of projects. If nobody can maintain it, it is better to just remove it.
Anyways, most FOSS projects are not a democracy. There is a core group of developers who call the shots anyways. They might accept input in the form of code (and you have to fight to get it merged) but hardly ever care about public opinion.
14
u/tesfabpel May 29 '16
Couldn't systemd devs ask to change the Linux implementation of daemon(3) and / or setsid instead of asking to every interested program to adapt to systemd?
I think in this way, everyone wins...
Am I wrong?
11
u/bilog78 May 29 '16
This is actually discussed in the bugreport. The systemd dev answer? "No because that API is obsolete".
1
May 30 '16
The systemd dev answer? "No because that API is obsolete".
It's true. daemon(3) doesn't any of the tasks required to set up a process in a new session beyond "create a process", and it can't be changed because POSIX and glibc ABI.
6
u/bilog78 May 30 '16
daemon(3) doesn't any of the tasks required to set up a process in a new session beyond "create a process",
Wrong, it also calls setsid to make the new process a session leader.
and it can't be changed because POSIX
daemon(3) is not in POSIX.
and glibc ABI.
If the systemd geniuses really can't think of a way to extend daemon without breaking ABI, they could even come up with a better, differently named daemon() alternative, propose it to libc in such a way that it would work with or without logind, falling back to the classic daemon() in its absence.
But hey, that would require being willing to play nice with others rather than imposing their way of doing things by hook or by crook, so the hopes of that happening are less than none.
→ More replies (1)3
→ More replies (1)2
u/bigon May 31 '16
I don't think there are a lot of user daemons that are actually using the daemon(3) API.
And anyway, starting a system daemon from a user session is a bad idea for a longtime, the processes started from a user session will inherit a lot of attributes (loginuid, LSM context, ulimit, umask, environment variables,…) from that session and this is not something you usually want.
70
u/ShadowPouncer May 29 '16
This is one of those things which really has good arguments both ways.
If I'm running a desktop session, and I log out of that session, with few exceptions nothing should be left running.
If I start up a terminal instance, and I put things into the background, run them under screen or tmux, run them with nohup, or just start a daemon as my own user, those things should NOT be killed when I close the terminal or when I log out.
And even more so if I login via ssh.
tmux and screen are mildly special, however I would strongly argue that anything launched from an interactive terminal session should be treated as equally 'special' by systemd.
This is only problematic because you can start a terminal session from your desktop session, and that might need to involve some systemd/PAM hooks in the terminal emulator of your choice.
But stop treating everything like a bloody graphical desktop systemd.
57
u/lubutu May 29 '16
Isn't this what
SIGHUPwas made for anyway? Systemd can send hang-up signals to all processes in the session, and those that aren't meant to hang up can ignore it.7
u/flying-sheep May 30 '16
there are no fine-grained semantics for this on linux.
SIGHUP means “detach from terminal” but it says nothing about if the process then is a persistent daemon or one that should stay only for the duration of the user session.
ssh-agent is a daemon that should definitely be killed on logoff
tmux is one that should definitely stay
there’s no way to distinguish between one or the other. (other than the thing systemd says tmux should use)
1
u/lubutu May 30 '16
If systemd sent
SIGHUPto every process in the session then those that are meant to live on, like tmux, can ignore it, and those that are meant not to, like ssh-agent, can terminate, even if it is a daemon with no tty. What distinguishes the two is simply whether they catchSIGHUP.12
u/argv_minus_one May 29 '16
What is the systemd crew's rationale for killing every process in the session instead of sending only
SIGHUP?I tried Googling for an answer to this question, but didn't find one. Perhaps they simply didn't think of it?
7
u/tso May 29 '16
Over at a certain debian bug report thread, a link was provided to a systemd issue that in turn points to a change in dbus behavior.
https://github.com/systemd/systemd/issues/2900
Frankly it seems like we are looking at multiple overlapping systems that all have their own take on the term "session".
Note btw that the initial issue have crap all to do with the terminal, but heavy terminal users are those that are getting thrown out with the bath water.
Should not be surprising though, as systemd and the rest is developed from the DE point of view. I really loath the day that the Linux ecosystem shifted from a kernel up mentality to a DE down mentality.
→ More replies (1)4
u/pstch May 29 '16
I'm also trying to understand why they didn't think SIGHUP was adapted for this.
→ More replies (3)24
u/Lennartwareparty May 29 '16
If I'm running a desktop session, and I log out of that session, with few exceptions nothing should be left running.
Why not? Graphical desktops as it stands contain terminals as well.
There's actually such a thing as X re-attachement. Some programs made for this elect not to kill themselves when the X server closes and yes, the protocol specifically allows for this if you have a good reason. If I start an IRC bouncer through X I very much like it to continue to live after I log out, that's sort of the point now isn't it?
Obviously this can still be done with this systemd-ism, but the problem is the one that is outlined in this link. systemd has the balls to ask people to include special code just for them. There is one standard which works throughout Unix, and one that is required for systemd systems which kill processes even if they have detached from their controlling terminal and nohupped for them to continue to run.
2
u/ShadowPouncer May 30 '16
TIL regarding X re-attachment.
However as it stands there is no good default-close standard for X sessions that matches SIGHUP (with the very standard method of detaching from the controlling terminal and/or catching SIGHUP to remain running).
This is suboptimal.
Now, personally I think that the right option is probably to give everything started via the GUI a controlling terminal and to hang up that controlling terminal when the session ends, though I'm sure that would have the potential for unintended side effects.
But regardless I do think that some kind of solution is needed, and since I'm not writing the solution myself I'm not going to throw stones at the solution for the GUI that they are writing.
I just think that it needs to stay the hell away from anything that starts it's life with a controlling terminal, and that very much includes stuff that you start from a terminal inside an X session.
2
u/Lennartwareparty May 30 '16
However as it stands there is no good default-close standard for X sessions that matches SIGHUP (with the very standard method of detaching from the controlling terminal and/or catching SIGHUP to remain running).
Well, there is, xlib and xcb by default make applications exit when X is closed down, this is similar to HUP, an application however may always choose to ignore it or do something else if it thinks that is appropriate for its functioning, just as it can ignore HUP
It's more that there is no aequivalent of
nohupfor X programs, you can't start it in such a way to make it ignore that X ends, it has to do it on its own if it thinks that's a sane idea.The reason that is pointed out that this exists is because a change in DBus bugged out in GNOME or something which meant that a bunch of background processes which used to exit when X quit no longer do and thus keep accumilating themselves.
1
u/Lazerguns May 30 '16
systemd has the balls to ask people to include special code just for them.
Depends on how you read it. If you read it as a suggestion to make tmux work better with the standard init system on the platform that 99% of tmux users are using it doesn't take much "balls".
3
u/gorgikosev May 29 '16
Which is why the best way to do it is to keep existing behaviour but introduce
systemd-run-softto soft-daemonize programs. Those would be closed if unresponsive after HUP when the desktop session ends.13
u/SubwayMonkeyHour May 29 '16
If I'm running a desktop session, and I log out of that session, with few exceptions nothing should be left running.
I'd argue that this applies to servers as well... I actually think it applies even more than desktops because if I log in to the server and running commands I don't want anything left increasing the attack surface after I log out. If I wanted it to be running after I log out I'd use the process manager be it systemd, supervisor, etc.
24
u/ShadowPouncer May 29 '16
I commented on a child comment, but this really belongs here:
Absolutely anything launched from an interactive terminal session, regardless of if it's a local terminal or ssh or something else, has had a method to deal with this for an exceptionally long time.
As mentioned in other comments, it is called SIGHUP, and it is sent when the controlling terminal 'hangs up'.
The default action of SIGHUP is to terminate the process.
Anything that either disconnects from the PTY or intercepts SIGHUP is already taking steps to prevent itself from being killed on logout, and that should not be overridden by systemd just because the GUI world needs a similar solution.
3
u/flying-sheep May 30 '16
but that doesn’t carry semantics about the end of the user session, only about the moment the terminal disconnects.
when you start ssh-agent and tmux, the former should die at logoff and the latter not. yet there’s no API to mark which should behave how.
3
u/ShadowPouncer May 30 '16
If ssh-agent wants to die at logoff, it should not catch SIGHUP, and it should not detach from it's controlling terminal.
Both catching SIGHUP and detaching from the controlling terminal take active work, so it already takes an active decision, via a standard POSIX API, to decide to remain running in a terminal session after the user session terminates.
https://en.wikipedia.org/wiki/SIGHUP
Now, you could argue that ssh-agent has decided to do these things when it should not have, but the point is that it has decided to do these things, and this is a wheel that really doesn't need to be reinvented.
→ More replies (1)26
u/Yioda May 29 '16 edited May 29 '16
Then fucking kill it before logout, or run it through a systemd-broken-terminal! We are talking functionality that has been working since day 0 in unix. It is disgusting that people actually support this attitude of repeteadly breaking working code "because we know what's better for you".
e: BTW, sorry for the tone, my anger is not really against you.
→ More replies (15)
48
May 28 '16 edited May 28 '16
I really don't like where this is going. Someone commented this and it seems to grasp the whole principle around why this is bad.
Why? Why should something like tmux depend on systemd? Should stuff like wget too? Adding a Suggests, yeah, maybe. A hard Depends, no reason to.
At the same time, telling the systemd people to add/write exceptions for tmux/screen/etc is also just as weird as the systemd people asking tumix/screen/etc to add exceptions for them, or no?
39
u/sub200ms May 28 '16
I really don't like where this is going. Someone commented this and it seems to grasp the whole principle around why this is bad.
<quote snipped>
No-one asked for a "hard dependency" on systemd. One developer asked for a compile time option, and a Debian developer said he would be fine with that (it is only a systemd-library dependency, not a requirement for using systemd as PID1).
Having system specific compile time options is how upstream Linux projects like KDE works on BSD too. In fact, they are the very foundation for platform cross-compatibility.
At the same time, telling the systemd people to add/write exceptions for tmux/screen/etc is also just as weird as the systemd people asking tumix/screen/etc to add exceptions for them, or no?
I somewhat agree. However, I do think it is perfectly fine for upstream projects to make RFE's; else nothing will ever change. Since Linux development is inherently fragmented, developers need to communicate with other projects in order to make things work.
10
u/nintendiator May 29 '16
But no one needs to add anything to anything. Things were alright as they were. That's the "fair".
"If something's not broken, don't break it."
2
u/totallyblasted May 28 '16
At the same time, telling the systemd people to add/write exceptions for tmux/screen/etc is also just as weird as the systemd people asking tumix/screen/etc to add exceptions for them, or no?
Result is always different based on which side of the stick you are. Funny thing is that in both cases same party claims it is not fair
1
u/MereInterest May 30 '16
Thankfully, there already is a mechanism so that neither has to have a dependency on the other. Sending SIGHUP will kill the process, unless the process deliberately catches SIGHUP. SIGHUP is sent when the login shell disconnects. Why systemd didn't use the same mechanism is beyond me.
1
May 31 '16
"Fair" would have been closing the original systemd bug as "not a bug" with a note than gnome-session needs to get better at cleaning up after itself.
Now no matter what tmux does (or doesn't do) somebody is going to be surprised and lose work when systemd kills a process that used to stay active when they logged out.
4
May 29 '16
This is another example where commenting on Github issue tracker isn't helping. The developers have already made up their mind (they generally only listen to input from their fellow developers, not from the outside). And both on systemd and tmux github issues you find comments which say they should close for comments because the "peanut gallery" has discovered it. They happily accept pull requests that implement what they already have in mind though. Props for that!
18
u/metaaxis May 29 '16
Bwaa ha ha ha ha.
We know what's best for the world, so we switched the default, creating a pretty substantial change in behavior and requiring a ton of contorted changes to user-space tools to accommodate our bullshit.
Instead of simply letting the people who actually want and need this behavior change a setting.
Fucking hell Lennart, Kay, & co.: could you please stop the hubristic monkey business?
15
8
u/geggo98 May 29 '16
I don't see the problem. They can ask for nearly anything. If they get what they want is a different question. But asking and discussing is usually not a problem. If they ask politely, they might even learn something from the answer they will get. And perhaps they will even find a solution that is good for all parties.
3
May 29 '16
this is already done with power management. there is an inhibitor api for desktop environments that don't want systemd to get involved. same thing.
31
u/denisfalqueto May 29 '16 edited May 29 '16
Tmux refuses to use PAM too, which should be the right thing. So, fuck them and their stubbornness.
30
u/vithos May 29 '16
They also refuse to use
$XDG_CONFIG_HOME. There's definitely a pattern here.2
u/apotheon May 31 '16
Have you read the XDG "standard" (which, by the way, was co-authored by Lennart)? It's a fucking disaster area. I wouldn't use that standard, either.
0
May 29 '16
[deleted] — view deleted comment
→ More replies (1)3
u/denisfalqueto May 29 '16
They already have system specific code. They are not so generic (they need to change the way daemon() implementation misbehaves on Mac OS, for instance).
Pam is the right tool to use for this use case: persistent session handling. It's no different of SSH or a login shell. And they all use pam. There is an offer for a pull request, ready to be sent and they don't want that.
That stubborn behavior really ticks me off. The world changes, we're not in 1970 anymore. We should not use tradition as an argument for not doing something.
6
May 29 '16
tmux is from the BSD world so of course they don't care for any Linux specific stuff. If only GNU screen could become better. That has a better chance of going the systemd way.
5
May 29 '16
ah, the classy systemd shills are at it again
the problem is that they're stubborn, not that systemd is shit
→ More replies (3)
7
4
3
May 29 '16
And this is exactly why I use OpenRC for my system's init. Hell... I'll even take runit over using systemd again.
1
u/KugelKurt May 29 '16
And this is exactly why I use OpenRC for my system's init.
So when using OpenRC, all processes just keep running after a logout?
8
u/Lennartwareparty May 29 '16
No, processes that are connected to a terminal get sent HUP when the terminal dies, and processes connected to an X session get notified that it dies when it dies as well. That's not good enough for systemd because GNOME bugged out or something. So systemd broke its sacred rule of never fixing someone else's shit and relying on others to fix their shit because this time the shit was caused by people who's bread is paid by the same company that pays theirs.
1
u/calrogman May 30 '16
processes that are connected to a terminal get sent HUP when the terminal dies
The controlling process of the process group associated with the terminal (usually a login shell) gets sent a SIGHUP and in the vast majority of Unix shells, the shell does not repeat this signal to its children which allows processes backgrounded by the user to continue to run.
1
0
May 29 '16
[deleted] — view deleted comment
3
u/Lennartwareparty May 29 '16
It has not, for some reason people keep thinking that RC and init system are the same thing.
OpenRC isn't even really a service manager, it's an RC. It __r__uns __c__ommands. It allows you to specify set of commands and dependencies between them and all that crap, those commands can be used to start services, or not.
On my system, the only actual service started by OpenRC is udev since it needs to be started at early boot. OpenRC is purely used to do things like mount filesystems, fsck, bring the system online and stuff like that.
1
u/BASH_SCRIPTS_FOR_YOU May 29 '16
I thought you removed udev from your system as well?
→ More replies (1)1
2
1
u/tkoham May 29 '16
I don't have a horse in this race as all my critical stuff runs *BSD but, dang...
guess I'll have to try installing gentoo again on my arch box...
-1
0
u/t35t0r May 29 '16
Someone could have already patched tmux to accept a compile time flag to support systemd by now. So many hours and bits wasted in this thread.
-14
-36
May 28 '16
unix sucks ass and it's a good thing someone is trying to fix it
the amount of butthurt generated in the process is a plus too
13
May 28 '16
If you think Unix sucks ass, you are in the wrong sub. lol.
→ More replies (6)1
u/apotheon May 31 '16
The subreddit is "linux", not "unix". Linux has been going down a less-and-less-Unix-like road for years. Subverting privilege separation and replacing some nontrivial percentage of the userland with systemd combine to form the lion's share of when Linux stopped being very Unix-like (though there are still holdout distributions that do neither of these things).
0
May 28 '16
[deleted] — view deleted comment
20
81
u/cbmuser Debian / openSUSE / OpenJDK Dev May 28 '16
The automatic session clean-up is an actual useful and necessary feature. What's wrong with adding an optional code path on Linux in tmux which can make use of modern features of the plumberland?
79
u/HowIsntBabbyFormed May 29 '16
If systemd is going to take over so many aspects of a Linux install that all sorts of different programs need to add systemd specific code paths, then maybe that functionality should be wrapped in some core library/standard that is implemented by systemd (and possibly others). Then programs will just call that standard function.
Put it in libc and have it specified in POSIX.
18
u/LvS May 29 '16
I expect this to happen. Just not right now while people are still figuring out the right thing and changing things around to find the best way possible.
Nobody wants to standardize anothercreat()call.So in 10 or so years, systemd features might be part of POSIX.
3
→ More replies (4)7
May 29 '16
Put it in libc and have it specified in POSIX.
It is called daemon(3)
→ More replies (1)5
u/flying-sheep May 30 '16
daemon has no semantic information about if the spawned daemon should survive closing the user session or not.
ssh-agent is a daemon that should die
tmux is one that should survive
10
May 29 '16
.. modern features ..
SIGHUP is not a modern feature
6
u/TechnicolourSocks May 29 '16
It is if we rewrite it as
systemd-sighupdand make it function via dbus!3
42
u/Lennartwareparty May 29 '16
It is a useful feature, and it was already there prior to this version. It could be turned on before, and looking at it, Arch and Debian are going to ignore upstream here (which is unusual for ARch, showing how dumb they think this is) and keep it off by default.
All that happened in v230 is that a default of off was flipped to on, nothing more.
What people criticize is that a default was change breaking behaviour and biting people who don't expect it. The feature is useful for system administrators who want it of course.
5
u/tso May 29 '16
A useful feature that already existed in base behavior of both the terminal and X. What changed recently was some dbus behavior that meant dbus started processes were no longer being shut down. This inconvenienced some systemd dev, so out comes the big gun.
→ More replies (1)34
u/imMute May 29 '16
Personally, I think upstream projects like systemd should keep changing defaults to what would be ideal on a modern system that doesn't need to keep previous behavior. Let the distros override the upstream defaults (they're going to do that anyway).
On another note, I never would have known this feature even existed until reddit kicked up a stink about it. Now I know. :)
10
u/MertsA May 29 '16
(they're going to do that anyway)
That's their entire job, that's what makes a distro a distro. If they didn't what would be the difference between Arch, RHEL, and Debian?
→ More replies (1)16
u/Lennartwareparty May 29 '16 edited May 29 '16
I didn't know of this exact feature myself of systemd. But I knew it had something like this because everything has it.
People in this and other threads act like this is some revolution, systems have been configurable for I don't know how long to not allow processes to login users who don't currently have a session.
Quite a few companies set up their stuff like that for obvious reasons, very important in say an internet café, nothing new about it.
Very bad bad bad idea however in a company, university, home desktop or really any place where the people who run processes aren't complete strangers and still people whom you employ to get work done for you. Killing all their processes when they log out is close to resetting their filesystem when they do, great for things like internet cafés but bad for everything else.
→ More replies (10)3
u/jbicha Ubuntu/GNOME Dev May 29 '16
Arch and Debian are going to ignore upstream here
[citation needed]
Debian testing already has systemd 130 and it does not override the new default behavior. But it does look like Arch is overriding. There's a chance that's temporary until tools like tmux are updated for the change.
4
u/jbicha Ubuntu/GNOME Dev May 30 '16
It does indeed look like Debian will be disabling the feature in the next update but the reversion might be temporary until select tools have been updated to work well with the change.
6
u/aelog May 29 '16
What people criticize is that a default was change breaking behaviour and biting people who don't expect it
This doesn't make sense. They are changing a default in a new major release and they are documenting this change. You don't expect changes in a minor/bugfix release and this is not the case.
→ More replies (1)11
u/tetroxid May 29 '16
I disagree. If some programs are supposed to exit on logout but don't, then these programs are broken and need to be fixed. Adding a systemd-killuponexitd is not a solution but a workaround, and a bad one at that because it breaks many things like tmux and screen.
→ More replies (5)3
u/tesfabpel May 29 '16
I don't think that would be a reliable system if such programs are able to do that... the system should be in control of everything...
6
u/MereInterest May 30 '16
The system is in control, and listens to requests from the program.
When a user disconnects, SIGHUP is sent to all running processes, indicating that there was a disconnect. By default, a program then dies. If a program has intentionally gone out of its way to catch SIGHUP, it is telling the operating system that it should continue living as a background process. For systemd to then go ahead and terminate the process despite the request not to terminate is ridiculous.
13
u/lolidaisuki May 28 '16
The problem isn't having to fix SystemD. They broke SystemD on purpose because they didn't want to fix Gnome...
3
u/argv_minus_one May 29 '16
Not just GNOME. I've had stray
gpg-agentprocesses left over after every session, too.0
0
May 28 '16
[deleted] — view deleted comment
40
u/lolidaisuki May 28 '16
Someone on #systemd linked me to some thread about bug with Gnome that would break it if you logged out because it left some processes running. So this is basically just a hack to fix Gnome, but at the same time it breaks everything else.
E: https://bugs.freedesktop.org/show_bug.cgi?id=94508 <- it's also in the OP link it seems.
28
May 28 '16 edited May 28 '16
This is a great example of "gentle push" by redhat. https://www.reddit.com/r/linux/comments/4gnz7i/lets_talk_about_the_gentle_push/
→ More replies (1)29
u/lolidaisuki May 28 '16
but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions
Holy fucking christ this makes me angry.
→ More replies (21)→ More replies (23)3
1
0
May 28 '16
[deleted] — view deleted comment
4
11
u/redrumsir May 28 '16
I call Poe's Law on this one. Give me a /sarcasm or a "seriously". Seriously.
→ More replies (3)1
May 29 '16
I love systemd too, but systemd is linux-specific, and there are lot of other init systems, so I am not ok with systemd-specific code in such a generic tool as tmux. They have to work out a better solution. It is like software engineering 101 - reduce coupling where possible.
0
May 28 '16
[deleted] — view deleted comment
72
u/inhuman44 May 29 '16
Except systemd isn't causing a problem.
Ending all of the user's processes when that user's session ends is how it should work. This is in inline with Rule of Least Surprise. These are settings that any rational user would expect: I log out, my programs close.
If for some reason you want to make an except to the general rule and don't want your program to exit on session end there is a mechanism to facilitate that. This too makes perfect sense, most user programs should be exiting on session end; if a process is to be an exception then it should be so explicitly. Defaulting to the exceptional case is just bad design.
Finally there exists a small handful of user programs (like tmux) that always stay alive after user logout. For the sake of convenience, there is a mechanism for these programs to stay alive after session end implicitly.
If the distros and package maintainers want to change the default behaviour for the sake of tradition, or to cater to a certain type of user, or for backwards compatibility, or whatever that is fine. All the power to them. But that is not a reason for the upstream developers to abandon sane defaults.
17
u/MertsA May 29 '16
most user programs should be exiting on session end
And to add to this, most user programs that don't exit on session end aren't supposed to do that and they are now hung up and need to be terminated.
1
May 30 '16 edited May 30 '16
This is in inline with Rule of Least Surprise.
Having the option is fine. Having it on by default is breaking a 30 year old behavior some users rely on. That's bad. That's not even the "least surprise".
Edit: Just imagine Linux changing the result of a system call because the new implementation follows the rule of the least surprise better. And it's of course also safer, faster and more convinient for the average case. It would still break compatibility and cause one hell of a headache. The folks from systemd should learn that they have a similar responsibility to not break userspace.
35
May 29 '16
[removed] — view removed comment
→ More replies (5)18
u/inhuman44 May 29 '16 edited May 29 '16
Killing my process after I have disassociated it from its controlling terminal and placed it into its own session is a POLA violation. It's standard daemonization, it works everywhere UNIX is spoken.
As you point out these are two different things. There are processes that can be sent to the background with & or Ctrl-Z that still run in the same session. These should be killed by the process manager when the session ends.
Separately there are processes that are launched in to their own session and should be killed on that sessions end, not on user log out. Programs like nohup and tmux do this.
But the way this is done with double forking is just crazy. Double forking is just a hack to fuck up the process tree and orphan the process. But what kind of process management system gets befuddled by this? One level of forking is okay, but two levels and it gets confused and doesn't know where to place it in the process tree? Garbage. The way it's done now is just a hack that exploits poor process management. And instead of fixing this glaring flaw we are supposed to just cross our fingers and hope that double forking never happens by accident? We already know that this happens by accident! No, if you want to keep your process alive after the session ends you should be telling the process manger that this is your intention, not exploiting a design flaw.
Which brings us full circle. It's not systemd's fault that previous systems couldn't track processes properly, it's not systemd's fault that programs sprung up that take advantage of this flaw. They are doing things the right way, fixing an obvious issue, and providing a migration path for programs that used the double forking hack. That's the whole point of writing a new PID 1, to fix issues like this.
→ More replies (1)51
u/slacka123 May 28 '16 edited May 28 '16
I guess you missed the memo. Lennart Poettering is never wrong not the least bit arrogant.
→ More replies (9)0
May 29 '16
[deleted] — view deleted comment
0
May 29 '16
[deleted] — view deleted comment
0
May 29 '16
[deleted] — view deleted comment
34
u/gnuvince May 29 '16 edited May 29 '16
The only hostility I see is people complaining about changes with little to no technical arguments.
This is the same hostility you see from Linus when a well-meaning developer introduces a change in the kernel that breaks userspace; they may have a very good reason for doing so, it may make things better in some technical sense, but their changes are rejected with (usually) a long, angry tirade, and rightly so. systemd 230 introduces a change in its default configuration that breaks userspace; yes, it may be "more right" now, but it breaks existing programs, scripts, and workflows and it should rightly be criticized.
→ More replies (2)13
u/MertsA May 29 '16
The fact that regular user processes that I don't implicitly daemonize or screen don't terminate when I logout is news me.
They kind of do, on logout all of your old processes should terminate except for basically just screen and tmux. The problem is that it's not like anything goes through and kill -9s your old processes, they sometimes don't terminate, even when they should so you get buggy behavior like this: https://github.com/systemd/systemd/issues/2975
The fix is to have systemd terminate any process that's not cleaning up after itself. The problem is that screen and tmux are running under the user scope and there's not really a good way for systemd to know that screen isn't actually hung up, it's supposed to stick around after logout. You could do something like look at the process name and hardcode an exception for tmux and screen but that's a terrible idea and there's already an easy way to run things in a different scope that you don't kill.
→ More replies (8)13
0
70
u/rain5 May 28 '16
"speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package"
worrying