16 ms·

Systemd v230 kills background processes after user logs out, breaks screen, tmux

152 points by polemic 10y ago

d3ckard 10y ago
Well, I guess that is a useful feature for init system.
- otterley 10y ago
  It's not a feature of the init system. It's a feature of the login daemon that ships with it.
  - digi_owl 10y ago
    Potato, potato...
madmax96 10y ago
This violates the rule of least surprise. Honestly, it looks like the Systemd maintainers operated without regards to the community at all. There's probably going to be some commenter who says "it only is surprising to you", but as evident by the email, it's surprising to a lot of users. Does anyone know if there's any precedent for a UNIX init system to behave like this? In my knowledge there isn't.
- eeperson 10y ago
  > Does anyone know if there's any precedent for a UNIX init system to behave like this? My guess is that previous init systems didn't do this because it wasn't really possible before cgroups. I'm certain that this behavior would be desired on multi-user systems to ensure that logged out users don't leave old processes lying around.
  - 0x0 10y ago
    For that, couldn't any old shell script run from cron or whatever and kill any process tree not attached to a tty or X console?
    - eeperson 10y ago
      Wouldn't that kill off anything started by init as well?
    - pdkl95 10y ago
      I've seen that a few times over a decade ago on a couple multiuser boxen at a university. As you suggest, someone simply wrote a custom script that killed off jobs for a few reasons. It cause problems, of course, especially if you didn't now about the server's limitations. However, in that specific situation - A shared server with hundreds of active[1] sessions - it was justified. What I find strange about systemd tying processes to an active session is that was something that was only needed in multiuser situations. The systemd advocates (and others) keep telling me that Linux isn't really multiuser anymore as justification for various incompatible changes. In the case of single user desktop (including netbook, tablet, etc) systems there's no need to kill off processes. [1] if you count idling in Pine as "active"
      - digi_owl 10y ago
        Systemd is undergoing continual scope creep. It may have started as Poetterings way to handle some transient daemons on his laptop, but has since grown to cover containerized servers (hello CoreOS) and multiseat (effectively turning a single X86 computer into a desktop terminal server). I sometimes wonder if the systemd people encourage the confusion about what systemd really is about, so that they can shortcircuit any debate by claiming their opposition is misunderstanding and therefore not fit to comment.
- AckSyn 10y ago
  > the Systemd maintainers operated without regards to the community at all Don't act surprised. Those asshats stomped over a whole lot of shit and everyone acts like they're the savior of the init (and a dozen other) systems.
  - toolz 10y ago
    Don't you feel like that's a little melodramatic? I mean they created open source software and forced exactly zero distro's or people to use it. I feel like every time I read about something with systemd someone is acting like there is a gun to their head to use it. If your distro of choice _chose_ to use systemd then your beef is with them forcing it on you...not systemd devs. They made an init system - your distro maintainers are the ones who decided it was the superior choice.
    - dingaling 10y ago
      systemd development is led by Red Hat, the $2 billion per annum gorilla in the corner. Third-party software, particularly from commercial vendors, typically uses Red Hat as the base system requirement. So you are correct, no-one holds a gun to distro maintainers' heads and forces systemd. They just find that there's no path forward without either [1] committing resources to keep abreast of the changes that systemd is creating both directly and indirectly or [2] just adopting systemd. Red Hat has won at this point through sheer persistence and clout, so most distros are going with option [2].
  - gnoway 10y ago
    Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and communication from systemd the development team. Personally I don't see what everyone is so upset about here. As pointed out by message 15, they've simply changed the default behavior and provided a long-opt setting to restore the old behavior if required; the hundreds or thousands of people who don't closely follow systemd will just be inconvenienced temporarily until they figure out wtf is going on, then they are back in business. And, maybe next time they'll pay closer attention. Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client.
- wallacoloo 10y ago
  > This violates the rule of least surprise. Maybe I'm completely misunderstanding things here, but when I log out, I expect all of my processes to be killed. When I'm logged off, and if another user logs on, it would be kind of weird if the system was still playing my music, etc, wouldn't it? If your processes don't die when you log off, then what exactly does it mean to "log off"? Or maybe the issue is that it's the init system doing this, rather than some other component?
  - Nursie 10y ago
    No, if I background and nohup something, it ought to stay there until or unless I kill it or it exits. What it means to log off is to end the session you're in. A desktop session would end all the windows and systray-type stuff you're running, a terminal session would end the shell. but any processes you have explicitly daemonised or nohup'd should carry on. Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing?
    - wallacoloo 10y ago
      > Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.
- geofft 10y ago
  > Does anyone know if there's any precedent for a UNIX init system to behave like this? I'm not sure if you'd call it an init system (but I guess any collection of shell scripts is a traditional UNIX init system), but MIT Athena has worked this way for many years: when you log out of a graphical session, there's an attempt to kill all your processes, because the machine should be fully for the use of whoever next logs in. Otherwise people would do long-running computing on machines in the computer labs ("clusters") and slow down interactive use for the next person -- and that's the non-malicious case. It used to be possible to get around this until some point in the late 2000s, when as part of unrelated rewriting, the logout script was set to just reboot the machine if it was unsure if it managed to clean everything up.
- JdeBP 10y ago
  There is, if six years of systemd having this counts as precedent. (-: The systemd people knew that this impacted the likes of screen and tmux, and there are discussions of this going back to 2010. Here's Jóhann B. Guðmundsson, erstwhile owner of the System 5 rc to systemd conversion project in Fedora, writing in July 2010, for example: * https://fedoraproject.org/w/index.php?title=User:Johannbg/QA/Systemd/Pam_systemd&oldid=187747#Options https://fedoraproject.org/w/index.php?title=User:Johannbg/QA...
jeanpralo 10y ago
I still can't find a good reasons why you should use systemd, this things grows out of control and is way out of the initial scope. Upstart was a reasonable replacement for system V I reckon, ...
- chatmasta 10y ago
  Socket activation is pretty cool. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... If you're hosting a bunch of apps for clients, but not all of them are being used all the time, then you can fit more onto one server by only activating them when they're used. I know Pantheon does this, for example. https://pantheon.io/open-source https://pantheon.io/open-source There has also been some discussion of integrating this functionality into kubernetes: https://github.com/kubernetes/kubernetes/issues/484 https://github.com/kubernetes/kubernetes/issues/484
  - jeanpralo 10y ago
    Thats is indeed pretty cool, the whole question is more under the way decisions are beeing taken regardless of what the community says. But I don't really see what this sort of feature has to do in an init process. I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu*. But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)
    - eeperson 10y ago
      I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do. For more details about the advantages of this can be found here[1] and here[2]. [1] - http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html [2] - http://0pointer.de/blog/projects/inetd.html http://0pointer.de/blog/projects/inetd.html
    - SwellJoe 10y ago
TheGuyWhoCodes 10y ago
WOW. That will break/surprise a lot of people unless the distros disable it at compile time. I use tmux regularly to start long running jobs. On the upside you can use loginctl with lingering to keep the processes after the user logs out.
- codehusker 10y ago
  This seems to be a common story. Systemd breaks one thing, but it's okay, they have their own built-in thing.
  - toyg 10y ago
    Or rather, systemd breaks an entire class of things, but it's okay, they have one and only one built-in thing.
    - misnome 10y ago
      It seems like the attitude "If you don't closely follow systemd development then you are an idiot and deserve what you get" is the most common. You shouldn't expect thousands and thousands of users to have to reconfigure to maintain existing, standard behaviour.
dijit 10y ago
This came up about a week ago, I questioned why it was a useful feature and people were quick to bark "security, if you don't like it you should be writing service/unit files for your programs." To me, I can't think of a single other operating system that works this way, even Windows. But I'm sure the pro-systemd supporters will "correct" my thinking. Additional: "You can just disable it, don't worry about the defaults" will be another argument that comes up, seems to be a nice way of stopping discussion.. it's the same thing people espoused when binary logging/journalctl was enforced.
- xyzzyz 10y ago
  To me, I can't think of a single other operating system that works this way, even Windows. But I'm sure the pro-systemd supporters will "correct" my thinking. Windows has stopped all the programs I had ran when I log out for as long as I remember.
  - JonathonW 10y ago
    But Windows also allows a session to disconnect without logging out. (This is the default when a remote session disconnects from the client side or due to network errors, and is prominently displayed in the UI otherwise.) For an ssh session on Linux, the traditional equivalent would be to run tmux/screen in the background, but systemd will happily kill them.
    - kazinator 10y ago
      You can similarly disconnect a VNC to a GNU/Linux desktop without logging it out. Speaking of which, if you run an Xvnc server in the background out of your shell and log out, this systemd problem will now kill it.
  - Arnavion 10y ago
    For RDP - Windows doesn't spawn a new session every time you remote into a machine if there's already an existing one, and closing the RDP window without logging out leaves the session running. But then again, the closest equivalent I can think of to an SSH session is Enter-PSSession, which does close all processes started under it when closing the session with Exit-PSSession.
mobystrip 10y ago
SystemD is the distro. Manifest destiny. There will be the kernel, and the distro system. Everything you like about "your distro" will cease to exist when we are done.
mrmondo 10y ago
To be fair, Debian Jessie is not exactly the most stunning of Debian releases over the past decade either. Between the missing and ancient packages we ended up having to move to CentOS 7 w/ epel+elrepo.
- rincebrain 10y ago
  Which packages were you finding "missing" or "ancient?"
  - mrmondo 10y ago
    Corosync, Pacemaker, OCF, they're off the top of my head but we found a LOT when looking at upgrading from Wheezy.
Scarbutt 10y ago
I wonder if the debian folks feel regrets about settling with systemd.
- iso-8859-1 10y ago
  Debian will disable this if they want.
  - morganvachon 10y ago
    But they shouldn't have to. Changing a default, known, long used feature of UNIX-like OSes without any sort of announcement or debate is dangerous and irresponsible. This kind of thing is why I feel the encroachment of systemd into most Linux distros is a bad thing. It's a great system in theory and I am excited about its potential, but it has some extremely egotistical and irresponsible developers who don't give a damn about what they break, as long as they can keep pushing code out without community testing or review to slow them down. Debian was flat out wrong to go with systemd until it reaches a certain level of maturity and stability, but there's no going back now.
    - mindslight 10y ago
      I think this is what happens when the "web 2.0" cancer leaks from the casino :/ FWIW "HandleLidSwitch=ignore" is another back-to-normal that will probably save you some walking.
    - justinsaccount 10y ago
      > without community testing or review This is a bug report in debian unstable against a bleeding edge version of systemd released 5 days ago.
      - morganvachon 10y ago
        They pushed this "feature" without any advance notice to developers of userland apps like screen and tmux, leaving them to pick up the pieces and figure out what happened. That is irresponsible and reckless. Common sense dictates that when you're going to introduce severe breakage, you give advance warning so it can be properly tested and dealt with. And it's having a negative effect on their own pet distro as well, see this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
kazinator 10y ago
Even "nohup" programs?
- mcguire 10y ago
  Apparently, according to the third message in the report.
  - kazinator 10y ago
    That's treading on hallowed grounds man. How can you teach newbies to use nohup now? "Oh, first you have to talk to the machine's administrator to reconfigure systemd, if you're on Linux. Or just use FreeBSD, MacOS, Solaris, or ... Cygwin".
    - justinsaccount 10y ago
      > or ... Cygwin Or not, because windows will kill all processes that are part of the users session when they log out.
      - wtbob 10y ago
        > Or not, because windows will kill all processes that are part of the users session when they log out. Ah-HA! Now we know what inspired this change. Is Poettering financed by Microsoft, or is he just a fan of their ease-of-use, high security and all-round wonderfulness?
- eeperson 10y ago
  Yes, but you can use 'systemd-run' to do something similar[1] [1]-https://github.com/systemd/systemd/blob/master/NEWS#L29 https://github.com/systemd/systemd/blob/master/NEWS#L29
  - kazinator 10y ago
    As a regular user, I don't want to know anything about systemd. I want the system to behave like Unix. The nohup utility is standardized by POSIX: Look here: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nohup.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/no...
kazinator 10y ago
Several years ago I was developing a "robust serial console over USB" feature for Linux. THis feature allows you to have a console on, say /dev/ttyUSB0. The device doesn't have to be plugged in. When you plug in the USB-Serial dongle, you have a console. You can unplug your serial dongle right in the middle of a session, plug in one that uses a different chip, and your session is intact! Just "Ctrl-L" to refresh your Vim window where you were editing and there you are. The /dev/ttyUSB0 did actually disappear when unplugged and did re-appear on the re-insertion, but the TTY session was isolated from that, held in a suspended state. Chopping apart the USB-Serial and TTY code in the kernel was relatively a piece of cake; but systemd threw up a wall, ironically! I got good help from the mailing list: https://lists.freedesktop.org/archives/systemd-devel/2013-May/011011.html https://lists.freedesktop.org/archives/systemd-devel/2013-Ma... At first I was stumped: everything should work, but what the heck is killing my login sessions when I unplug the device? I went over the code to make absolutely sure nothing would be getting a hangup signal from the TTY or the like. Through kernel printk messages, I traced it to systemd, slapping my forehead. Basically, even though the tty session was being kept intact, it was the fact that the USB device went away that systemd killed the session. Once I solved the systemd issues, everything worked great. systemd: it just likes to kill things, at least in its default configuration.
- 0x0 10y ago
  I can't believe the attitude you received in some of those replies :-/
  - uuoc 10y ago
    Actually, that attitude is exactly what one receives from the systemd crew. They, and only they, know what you want, when you want it, and they always know better than you do. That's why the systemd crew generates such great hatred.
  - misnome 10y ago
    I love that the long, flaming reply so obviously didn't read the entire report, went on to lecture how to change the behaviour, and completely ignored the questions of expectation.
vxxzy 10y ago
What about user-specific CRON jobs? Does this prevent them from running?
mcguire 10y ago
The response to the bug report: Hello, You should quote the full changelog and not just the part that is 'bad' in your mind. >systemd-logind will now by default terminate user processes that are part of >the user session scope unit (session-XX.scope) when the user logs out. This >behavior is controlled by the KillUserProcesses= setting in logind.conf, and >the previous default of "no" is now changed to "yes". For debian it would be enough to set this to "no" again with --without-kill-user-processes option to "configure" >This means that user sessions will be properly cleaned up after, but >additional steps are necessary to allow intentionally long-running processes >to survive logout. Here comes the important part. Seems like the systemd-devs are working on a way to allow intentionally long-running processes in a specific user scope. And here is another way for allowing these long-running processes: >While the user is logged in at least once, user@.service is running, and any >service that should survive the end of any individual login session can be >started at a user service or scope using systemd-run. systemd-run(1) man >page has been extended with an example which shows how to run screen in a >scope unit underneath user@.service. The same command works for tmux. And another way for allowing long-running processes. >After the user logs out of all sessions, user@.service will be terminated >too, by default, unless the user has "lingering" enabled. To effectively >allow users to run long-term tasks even if they are logged out, lingering >must be enabled for them. See loginctl(1) for details. The default polkit >policy was modified to allow users to set lingering for themselves without >authentication. > >Previous defaults can be restored at compile time by the >--without-kill-user-processes option to "configure" You see? No reason to complain about. Best regards Christian Rebischke. tl;dr: You can configure it not to, or you can accept that Linux is about as much a "Unix" as AIX, Irix, or HP-UX and join them in the wonderful land of the future, which suspiciously resembles the time before all the non-standard vendors died. I'll stop now, before I make Linus on a backwards compatibility rant look like a choir boy in church.
- TwoNineFive 10y ago
  Wow. Christian Rebischke's response to this reasonable, mild-mannered, bug report, is unbelievably hostile. Now he's out on Twitter describing the bug as a "hate-report". With any hope, a future employer will find this, put it in front of him, and ask if that's the kind of behavior that should be expected of him. Before turning him around and out the door.
gdamjan1 10y ago
This is a good feature, and a good default. Processes in the session-xx.scope should be stopped when the session ends. there's an easy sollution for processes that don't need to be stopped too.
- caf 10y ago
  No, there was already a mechanism in place to end processes when you log out - when the controlling tty disappears, every process in the session is sent a SIGHUP and SIGCONT signal. The processes started under screen(1) are deliberately created with a new pty as controlling tty and in a new session, because they are intended to survive the ending of the original session where screen was started.
  - gdamjan1 10y ago
    not for processes that don't have a controlling tty. processes deliberatelly started with screen can be started with systemd-run screen.
tbyehl 10y ago
So if I set /etc/systemd/logind.conf KillUserProcesses=no the current behavior will be preserved whenever this change finds its way downstream?
AnonymousPlanet 10y ago
This is what you get if you have people in charge of developing an init system who never did any professional admin work and who apparently have a disdain for everything Unix stands for.
- IshKebab 10y ago
  Maybe they want to improve Unix? This is undeniably the correct behaviour. It's only bad because everyone has gotten used to how things worked in the 70s.
  - AnonymousPlanet 10y ago
    I believe we have to discern between Unix as a concrete implementation (what is a process, where do certain files go, etc.) and the design philosophy. My remark focused on the latter. I would very much like to see modernization in Unix as a technology. At the same time, I believe that Linux owes its success to the adherence to a number of Unix design philosophies. This has kept Linux flexible across a wide spectrum of use cases and prevented it from running into a dead end, becoming stale. Abandoning these foundations in order to optimize towards a very structured, hierarchical engineering ideal, will make Linux go more in the direction of BeOS or Windows. And I'm afraid that we don't have the resources that Microsoft uses to keep Windows competitive and backwards compatible.
ChuckMcM 10y ago
This feels like another land grab for the user experience by systemd. They have successfully screwed up a lot of sysadmin's habits and now they are going after the everyday users. Sigh.
- Spooky23 10y ago
  Gotta love systemd, they are always solving problems that you don't have, then yelling at you for not having them.
- digi_owl 10y ago
  Pretty much. More and more it feels like a bunch of disgruntled ex kernel devs have found a way to circumvent Torvalds, basically using Linux as a source of drivers and base plumbing. I'm just waiting for them to reimplement coreutils and sh as systemd binaries (they did have plans for a user space tty implementation, iirc).
  - ChuckMcM 10y ago
    To be honest I had not considered that angle. If you were going to write the equivalent of "Windows 3.1" for Linux how would you start? For those to young to remember (or care :-) Windows 3.1 was the commercially successful version of Windows where all of the "user experience" had been abstracted into the Windows libraries, leaving the MS-DOS kernel underneath for legacy APIs and driver support. The DOS kernel, once the "center of attention" became irrelevant. If the systemd folks can get everyone to write applications to the systemd APIs, then the Linux kernel people are just plumbers who you can yell at if they don't support the latest networking chip or USB gizmo, but aren't really contributing things to the system that users see. Its brilliant in a way, and the more I think about it the more plausible it seems.
    - digi_owl 10y ago
      Well it is in large part what Android is doing already. Most apps there live inside the Android JVM after all.
otterley 10y ago
I think this is actually a useful change in default behavior for server environments, which comprise the vast majority of Linux installations. Being able to assure by default that all of a user's spawned processes are terminated when the user logs out is a much more secure default behavior than the opposite. This means if I disable a user in LDAP and force the user to log out, I don't have to worry about lingering processes that might be malicious or pose some sort of threat to my server or data. Keep in mind that there is a switch in logind to enable lingering that you can enable if you don't like it. Besides, the release notes provided the workaround in line, so that interested users wouldn't have to hunt for a solution.
- Nursie 10y ago
  For most development server use-cases, it's pretty terrible though. Screen is how a lot of people work.
  - ams6110 10y ago
    Yep -- I use tmux myself, but I'll have tmux sessions running for months on my work machine, so that I can ssh in and be immediately productive from anywhere.
- feld 10y ago
  It's a POLA violation. Documenting this gross violation of expectations is not a sufficient apology.
  - geofft 10y ago
    (I assume you meant POLS, not POLA?)
    - khedoros 10y ago
      "POLA" would be for "astonishment", instead of "surprise". Based on the Wikipedia citations, POLA looks like the older form of the phrase.
digi_owl 10y ago
I noticed the entry for this in their release note, and my first thought was that this would catch many off guard...
shirro 10y ago
I like systemd. It solves a lot of problems and does some cool things. But it always worries me when they go around breaking stuff. Too often the response is something like tmux has been doing it wrong - use the new systemd-tmux service instead.
dkarapetyan 10y ago
Time to switch to one of the BSDs. I hear they're a better unix than unix and these systemd clowns are out of control.
- anonbanker 10y ago
  try Calculate Linux first before going full BSD. you'll thank me.
  - dkarapetyan 10y ago
    Will do.
- Wildgoose 10y ago
  Gentoo still lets you avoid systemd - I've switched to Gentoo and have been pleasantly surprised at how nicely everything runs. Mind you, I have also started investigating the BSD family seriously (rather than just to have a play with), just in case.
gargravarr 10y ago
I am certainly not surprised by this change. I'm just glad I switched to Devuan a few months ago. I don't read every changelog, but I would have been furious if I'd discovered my screen session gone. Having this enabled by default is moronic and shows real short-sightedness on the part of the Debian packagers.
cmurf 10y ago
As far as I've experienced on OS X, any running process does not survive logout. Granted it's a single session, and that session is also GUI. For a GUI login, I'd expect systemd to do exactly this. Right now, wayward processes ignore or just don't grok whatever "quit" notification the DE sends, and this will cause delayed restart/shutdown for 1m30s at which point systemd kills the user session. 1m30s is too long. Whereas on GUIless server, where I use tmux, the idea I'd login, run tmux and create a session or two, detach, logout, and by logging out all my tmux sessions go poof is not expected. But even in the cited thread there's a mechanism for such processes to get a separate user session.
- wtbob 10y ago
  > For a GUI login, I'd expect systemd to do exactly this. Processes have always done this when they receive a hangup (HUP) signal (unless they do something else, of course, but that's up to them). > But even in the cited thread there's a mechanism for such processes to get a separate user session. That mechanism has existed for decades: it's called nohup.
deleted 10y ago
[deleted]
digi_owl 10y ago
And now tmux is asked to accommodate the change. https://github.com/tmux/tmux/issues/428 https://github.com/tmux/tmux/issues/428

152 points by polemic 10y ago

d3ckard 10y ago

Well, I guess that is a useful feature for init system.

otterley 10y ago
It's not a feature of the init system. It's a feature of the login daemon that ships with it.
- digi_owl 10y ago
  Potato, potato...

madmax96 10y ago

This violates the rule of least surprise. Honestly, it looks like the Systemd maintainers operated without regards to the community at all. There's probably going to be some commenter who says "it only is surprising to you", but as evident by the email, it's surprising to a lot of users. Does anyone know if there's any precedent for a UNIX init system to behave like this? In my knowledge there isn't.

eeperson 10y ago
> Does anyone know if there's any precedent for a UNIX init system to behave like this? My guess is that previous init systems didn't do this because it wasn't really possible before cgroups. I'm certain that this behavior would be desired on multi-user systems to ensure that logged out users don't leave old processes lying around.
- 0x0 10y ago
  For that, couldn't any old shell script run from cron or whatever and kill any process tree not attached to a tty or X console?
  - eeperson 10y ago
    Wouldn't that kill off anything started by init as well?
  - pdkl95 10y ago
    I've seen that a few times over a decade ago on a couple multiuser boxen at a university. As you suggest, someone simply wrote a custom script that killed off jobs for a few reasons. It cause problems, of course, especially if you didn't now about the server's limitations. However, in that specific situation - A shared server with hundreds of active[1] sessions - it was justified. What I find strange about systemd tying processes to an active session is that was something that was only needed in multiuser situations. The systemd advocates (and others) keep telling me that Linux isn't really multiuser anymore as justification for various incompatible changes. In the case of single user desktop (including netbook, tablet, etc) systems there's no need to kill off processes. [1] if you count idling in Pine as "active"
    - digi_owl 10y ago
      Systemd is undergoing continual scope creep. It may have started as Poetterings way to handle some transient daemons on his laptop, but has since grown to cover containerized servers (hello CoreOS) and multiseat (effectively turning a single X86 computer into a desktop terminal server). I sometimes wonder if the systemd people encourage the confusion about what systemd really is about, so that they can shortcircuit any debate by claiming their opposition is misunderstanding and therefore not fit to comment.
AckSyn 10y ago
> the Systemd maintainers operated without regards to the community at all Don't act surprised. Those asshats stomped over a whole lot of shit and everyone acts like they're the savior of the init (and a dozen other) systems.
- toolz 10y ago
  Don't you feel like that's a little melodramatic? I mean they created open source software and forced exactly zero distro's or people to use it. I feel like every time I read about something with systemd someone is acting like there is a gun to their head to use it. If your distro of choice _chose_ to use systemd then your beef is with them forcing it on you...not systemd devs. They made an init system - your distro maintainers are the ones who decided it was the superior choice.
  - dingaling 10y ago
    systemd development is led by Red Hat, the $2 billion per annum gorilla in the corner. Third-party software, particularly from commercial vendors, typically uses Red Hat as the base system requirement. So you are correct, no-one holds a gun to distro maintainers' heads and forces systemd. They just find that there's no path forward without either [1] committing resources to keep abreast of the changes that systemd is creating both directly and indirectly or [2] just adopting systemd. Red Hat has won at this point through sheer persistence and clout, so most distros are going with option [2].
- gnoway 10y ago
  Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and communication from systemd the development team. Personally I don't see what everyone is so upset about here. As pointed out by message 15, they've simply changed the default behavior and provided a long-opt setting to restore the old behavior if required; the hundreds or thousands of people who don't closely follow systemd will just be inconvenienced temporarily until they figure out wtf is going on, then they are back in business. And, maybe next time they'll pay closer attention. Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client.
wallacoloo 10y ago
> This violates the rule of least surprise. Maybe I'm completely misunderstanding things here, but when I log out, I expect all of my processes to be killed. When I'm logged off, and if another user logs on, it would be kind of weird if the system was still playing my music, etc, wouldn't it? If your processes don't die when you log off, then what exactly does it mean to "log off"? Or maybe the issue is that it's the init system doing this, rather than some other component?
- Nursie 10y ago
  No, if I background and nohup something, it ought to stay there until or unless I kill it or it exits. What it means to log off is to end the session you're in. A desktop session would end all the windows and systray-type stuff you're running, a terminal session would end the shell. but any processes you have explicitly daemonised or nohup'd should carry on. Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing?
  - wallacoloo 10y ago
    > Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.
geofft 10y ago
> Does anyone know if there's any precedent for a UNIX init system to behave like this? I'm not sure if you'd call it an init system (but I guess any collection of shell scripts is a traditional UNIX init system), but MIT Athena has worked this way for many years: when you log out of a graphical session, there's an attempt to kill all your processes, because the machine should be fully for the use of whoever next logs in. Otherwise people would do long-running computing on machines in the computer labs ("clusters") and slow down interactive use for the next person -- and that's the non-malicious case. It used to be possible to get around this until some point in the late 2000s, when as part of unrelated rewriting, the logout script was set to just reboot the machine if it was unsure if it managed to clean everything up.
JdeBP 10y ago
There is, if six years of systemd having this counts as precedent. (-: The systemd people knew that this impacted the likes of screen and tmux, and there are discussions of this going back to 2010. Here's Jóhann B. Guðmundsson, erstwhile owner of the System 5 rc to systemd conversion project in Fedora, writing in July 2010, for example: * https://fedoraproject.org/w/index.php?title=User:Johannbg/QA/Systemd/Pam_systemd&oldid=187747#Options https://fedoraproject.org/w/index.php?title=User:Johannbg/QA...

jeanpralo 10y ago

I still can't find a good reasons why you should use systemd, this things grows out of control and is way out of the initial scope. Upstart was a reasonable replacement for system V I reckon, ...

chatmasta 10y ago
Socket activation is pretty cool. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... If you're hosting a bunch of apps for clients, but not all of them are being used all the time, then you can fit more onto one server by only activating them when they're used. I know Pantheon does this, for example. https://pantheon.io/open-source https://pantheon.io/open-source There has also been some discussion of integrating this functionality into kubernetes: https://github.com/kubernetes/kubernetes/issues/484 https://github.com/kubernetes/kubernetes/issues/484
- jeanpralo 10y ago
  Thats is indeed pretty cool, the whole question is more under the way decisions are beeing taken regardless of what the community says. But I don't really see what this sort of feature has to do in an init process. I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu*. But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)
  - eeperson 10y ago
    I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do. For more details about the advantages of this can be found here[1] and here[2]. [1] - http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html [2] - http://0pointer.de/blog/projects/inetd.html http://0pointer.de/blog/projects/inetd.html
  - SwellJoe 10y ago

TheGuyWhoCodes 10y ago

WOW. That will break/surprise a lot of people unless the distros disable it at compile time. I use tmux regularly to start long running jobs. On the upside you can use loginctl with lingering to keep the processes after the user logs out.

codehusker 10y ago
This seems to be a common story. Systemd breaks one thing, but it's okay, they have their own built-in thing.
- toyg 10y ago
  Or rather, systemd breaks an entire class of things, but it's okay, they have one and only one built-in thing.
  - misnome 10y ago
    It seems like the attitude "If you don't closely follow systemd development then you are an idiot and deserve what you get" is the most common. You shouldn't expect thousands and thousands of users to have to reconfigure to maintain existing, standard behaviour.

dijit 10y ago

This came up about a week ago, I questioned why it was a useful feature and people were quick to bark "security, if you don't like it you should be writing service/unit files for your programs." To me, I can't think of a single other operating system that works this way, even Windows. But I'm sure the pro-systemd supporters will "correct" my thinking. Additional: "You can just disable it, don't worry about the defaults" will be another argument that comes up, seems to be a nice way of stopping discussion.. it's the same thing people espoused when binary logging/journalctl was enforced.

xyzzyz 10y ago
To me, I can't think of a single other operating system that works this way, even Windows. But I'm sure the pro-systemd supporters will "correct" my thinking. Windows has stopped all the programs I had ran when I log out for as long as I remember.
- JonathonW 10y ago
  But Windows also allows a session to disconnect without logging out. (This is the default when a remote session disconnects from the client side or due to network errors, and is prominently displayed in the UI otherwise.) For an ssh session on Linux, the traditional equivalent would be to run tmux/screen in the background, but systemd will happily kill them.
  - kazinator 10y ago
    You can similarly disconnect a VNC to a GNU/Linux desktop without logging it out. Speaking of which, if you run an Xvnc server in the background out of your shell and log out, this systemd problem will now kill it.
- Arnavion 10y ago
  For RDP - Windows doesn't spawn a new session every time you remote into a machine if there's already an existing one, and closing the RDP window without logging out leaves the session running. But then again, the closest equivalent I can think of to an SSH session is Enter-PSSession, which does close all processes started under it when closing the session with Exit-PSSession.

mobystrip 10y ago

SystemD is the distro. Manifest destiny. There will be the kernel, and the distro system. Everything you like about "your distro" will cease to exist when we are done.

mrmondo 10y ago

To be fair, Debian Jessie is not exactly the most stunning of Debian releases over the past decade either. Between the missing and ancient packages we ended up having to move to CentOS 7 w/ epel+elrepo.

rincebrain 10y ago
Which packages were you finding "missing" or "ancient?"
- mrmondo 10y ago
  Corosync, Pacemaker, OCF, they're off the top of my head but we found a LOT when looking at upgrading from Wheezy.

Scarbutt 10y ago

I wonder if the debian folks feel regrets about settling with systemd.

iso-8859-1 10y ago
Debian will disable this if they want.
- morganvachon 10y ago
  But they shouldn't have to. Changing a default, known, long used feature of UNIX-like OSes without any sort of announcement or debate is dangerous and irresponsible. This kind of thing is why I feel the encroachment of systemd into most Linux distros is a bad thing. It's a great system in theory and I am excited about its potential, but it has some extremely egotistical and irresponsible developers who don't give a damn about what they break, as long as they can keep pushing code out without community testing or review to slow them down. Debian was flat out wrong to go with systemd until it reaches a certain level of maturity and stability, but there's no going back now.
  - mindslight 10y ago
    I think this is what happens when the "web 2.0" cancer leaks from the casino :/ FWIW "HandleLidSwitch=ignore" is another back-to-normal that will probably save you some walking.
  - justinsaccount 10y ago
    > without community testing or review This is a bug report in debian unstable against a bleeding edge version of systemd released 5 days ago.
    - morganvachon 10y ago
      They pushed this "feature" without any advance notice to developers of userland apps like screen and tmux, leaving them to pick up the pieces and figure out what happened. That is irresponsible and reckless. Common sense dictates that when you're going to introduce severe breakage, you give advance warning so it can be properly tested and dealt with. And it's having a negative effect on their own pet distro as well, see this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...

kazinator 10y ago

Even "nohup" programs?

mcguire 10y ago
Apparently, according to the third message in the report.
- kazinator 10y ago
  That's treading on hallowed grounds man. How can you teach newbies to use nohup now? "Oh, first you have to talk to the machine's administrator to reconfigure systemd, if you're on Linux. Or just use FreeBSD, MacOS, Solaris, or ... Cygwin".
  - justinsaccount 10y ago
    > or ... Cygwin Or not, because windows will kill all processes that are part of the users session when they log out.
    - wtbob 10y ago
      > Or not, because windows will kill all processes that are part of the users session when they log out. Ah-HA! Now we know what inspired this change. Is Poettering financed by Microsoft, or is he just a fan of their ease-of-use, high security and all-round wonderfulness?
eeperson 10y ago
Yes, but you can use 'systemd-run' to do something similar[1] [1]-https://github.com/systemd/systemd/blob/master/NEWS#L29 https://github.com/systemd/systemd/blob/master/NEWS#L29
- kazinator 10y ago
  As a regular user, I don't want to know anything about systemd. I want the system to behave like Unix. The nohup utility is standardized by POSIX: Look here: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nohup.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/no...

kazinator 10y ago

Several years ago I was developing a "robust serial console over USB" feature for Linux. THis feature allows you to have a console on, say /dev/ttyUSB0. The device doesn't have to be plugged in. When you plug in the USB-Serial dongle, you have a console. You can unplug your serial dongle right in the middle of a session, plug in one that uses a different chip, and your session is intact! Just "Ctrl-L" to refresh your Vim window where you were editing and there you are. The /dev/ttyUSB0 did actually disappear when unplugged and did re-appear on the re-insertion, but the TTY session was isolated from that, held in a suspended state. Chopping apart the USB-Serial and TTY code in the kernel was relatively a piece of cake; but systemd threw up a wall, ironically! I got good help from the mailing list: https://lists.freedesktop.org/archives/systemd-devel/2013-May/011011.html https://lists.freedesktop.org/archives/systemd-devel/2013-Ma... At first I was stumped: everything should work, but what the heck is killing my login sessions when I unplug the device? I went over the code to make absolutely sure nothing would be getting a hangup signal from the TTY or the like. Through kernel printk messages, I traced it to systemd, slapping my forehead. Basically, even though the tty session was being kept intact, it was the fact that the USB device went away that systemd killed the session. Once I solved the systemd issues, everything worked great. systemd: it just likes to kill things, at least in its default configuration.

0x0 10y ago
I can't believe the attitude you received in some of those replies :-/
- uuoc 10y ago
  Actually, that attitude is exactly what one receives from the systemd crew. They, and only they, know what you want, when you want it, and they always know better than you do. That's why the systemd crew generates such great hatred.
- misnome 10y ago
  I love that the long, flaming reply so obviously didn't read the entire report, went on to lecture how to change the behaviour, and completely ignored the questions of expectation.

vxxzy 10y ago

What about user-specific CRON jobs? Does this prevent them from running?

mcguire 10y ago

The response to the bug report: Hello, You should quote the full changelog and not just the part that is 'bad' in your mind. >systemd-logind will now by default terminate user processes that are part of >the user session scope unit (session-XX.scope) when the user logs out. This >behavior is controlled by the KillUserProcesses= setting in logind.conf, and >the previous default of "no" is now changed to "yes". For debian it would be enough to set this to "no" again with --without-kill-user-processes option to "configure" >This means that user sessions will be properly cleaned up after, but >additional steps are necessary to allow intentionally long-running processes >to survive logout. Here comes the important part. Seems like the systemd-devs are working on a way to allow intentionally long-running processes in a specific user scope. And here is another way for allowing these long-running processes: >While the user is logged in at least once, user@.service is running, and any >service that should survive the end of any individual login session can be >started at a user service or scope using systemd-run. systemd-run(1) man >page has been extended with an example which shows how to run screen in a >scope unit underneath user@.service. The same command works for tmux. And another way for allowing long-running processes. >After the user logs out of all sessions, user@.service will be terminated >too, by default, unless the user has "lingering" enabled. To effectively >allow users to run long-term tasks even if they are logged out, lingering >must be enabled for them. See loginctl(1) for details. The default polkit >policy was modified to allow users to set lingering for themselves without >authentication. > >Previous defaults can be restored at compile time by the >--without-kill-user-processes option to "configure" You see? No reason to complain about. Best regards Christian Rebischke. tl;dr: You can configure it not to, or you can accept that Linux is about as much a "Unix" as AIX, Irix, or HP-UX and join them in the wonderful land of the future, which suspiciously resembles the time before all the non-standard vendors died. I'll stop now, before I make Linus on a backwards compatibility rant look like a choir boy in church.

TwoNineFive 10y ago
Wow. Christian Rebischke's response to this reasonable, mild-mannered, bug report, is unbelievably hostile. Now he's out on Twitter describing the bug as a "hate-report". With any hope, a future employer will find this, put it in front of him, and ask if that's the kind of behavior that should be expected of him. Before turning him around and out the door.

gdamjan1 10y ago

This is a good feature, and a good default. Processes in the session-xx.scope should be stopped when the session ends. there's an easy sollution for processes that don't need to be stopped too.

caf 10y ago
No, there was already a mechanism in place to end processes when you log out - when the controlling tty disappears, every process in the session is sent a SIGHUP and SIGCONT signal. The processes started under screen(1) are deliberately created with a new pty as controlling tty and in a new session, because they are intended to survive the ending of the original session where screen was started.
- gdamjan1 10y ago
  not for processes that don't have a controlling tty. processes deliberatelly started with screen can be started with systemd-run screen.

tbyehl 10y ago

So if I set /etc/systemd/logind.conf KillUserProcesses=no the current behavior will be preserved whenever this change finds its way downstream?

AnonymousPlanet 10y ago

This is what you get if you have people in charge of developing an init system who never did any professional admin work and who apparently have a disdain for everything Unix stands for.

IshKebab 10y ago
Maybe they want to improve Unix? This is undeniably the correct behaviour. It's only bad because everyone has gotten used to how things worked in the 70s.
- AnonymousPlanet 10y ago
  I believe we have to discern between Unix as a concrete implementation (what is a process, where do certain files go, etc.) and the design philosophy. My remark focused on the latter. I would very much like to see modernization in Unix as a technology. At the same time, I believe that Linux owes its success to the adherence to a number of Unix design philosophies. This has kept Linux flexible across a wide spectrum of use cases and prevented it from running into a dead end, becoming stale. Abandoning these foundations in order to optimize towards a very structured, hierarchical engineering ideal, will make Linux go more in the direction of BeOS or Windows. And I'm afraid that we don't have the resources that Microsoft uses to keep Windows competitive and backwards compatible.

ChuckMcM 10y ago

This feels like another land grab for the user experience by systemd. They have successfully screwed up a lot of sysadmin's habits and now they are going after the everyday users. Sigh.

Spooky23 10y ago
Gotta love systemd, they are always solving problems that you don't have, then yelling at you for not having them.
digi_owl 10y ago
Pretty much. More and more it feels like a bunch of disgruntled ex kernel devs have found a way to circumvent Torvalds, basically using Linux as a source of drivers and base plumbing. I'm just waiting for them to reimplement coreutils and sh as systemd binaries (they did have plans for a user space tty implementation, iirc).
- ChuckMcM 10y ago
  To be honest I had not considered that angle. If you were going to write the equivalent of "Windows 3.1" for Linux how would you start? For those to young to remember (or care :-) Windows 3.1 was the commercially successful version of Windows where all of the "user experience" had been abstracted into the Windows libraries, leaving the MS-DOS kernel underneath for legacy APIs and driver support. The DOS kernel, once the "center of attention" became irrelevant. If the systemd folks can get everyone to write applications to the systemd APIs, then the Linux kernel people are just plumbers who you can yell at if they don't support the latest networking chip or USB gizmo, but aren't really contributing things to the system that users see. Its brilliant in a way, and the more I think about it the more plausible it seems.
  - digi_owl 10y ago
    Well it is in large part what Android is doing already. Most apps there live inside the Android JVM after all.

otterley 10y ago

I think this is actually a useful change in default behavior for server environments, which comprise the vast majority of Linux installations. Being able to assure by default that all of a user's spawned processes are terminated when the user logs out is a much more secure default behavior than the opposite. This means if I disable a user in LDAP and force the user to log out, I don't have to worry about lingering processes that might be malicious or pose some sort of threat to my server or data. Keep in mind that there is a switch in logind to enable lingering that you can enable if you don't like it. Besides, the release notes provided the workaround in line, so that interested users wouldn't have to hunt for a solution.

Nursie 10y ago
For most development server use-cases, it's pretty terrible though. Screen is how a lot of people work.
- ams6110 10y ago
  Yep -- I use tmux myself, but I'll have tmux sessions running for months on my work machine, so that I can ssh in and be immediately productive from anywhere.
feld 10y ago
It's a POLA violation. Documenting this gross violation of expectations is not a sufficient apology.
- geofft 10y ago
  (I assume you meant POLS, not POLA?)
  - khedoros 10y ago
    "POLA" would be for "astonishment", instead of "surprise". Based on the Wikipedia citations, POLA looks like the older form of the phrase.

digi_owl 10y ago

I noticed the entry for this in their release note, and my first thought was that this would catch many off guard...

shirro 10y ago

I like systemd. It solves a lot of problems and does some cool things. But it always worries me when they go around breaking stuff. Too often the response is something like tmux has been doing it wrong - use the new systemd-tmux service instead.

dkarapetyan 10y ago

Time to switch to one of the BSDs. I hear they're a better unix than unix and these systemd clowns are out of control.

anonbanker 10y ago
try Calculate Linux first before going full BSD. you'll thank me.
- dkarapetyan 10y ago
  Will do.
Wildgoose 10y ago
Gentoo still lets you avoid systemd - I've switched to Gentoo and have been pleasantly surprised at how nicely everything runs. Mind you, I have also started investigating the BSD family seriously (rather than just to have a play with), just in case.

gargravarr 10y ago

I am certainly not surprised by this change. I'm just glad I switched to Devuan a few months ago. I don't read every changelog, but I would have been furious if I'd discovered my screen session gone. Having this enabled by default is moronic and shows real short-sightedness on the part of the Debian packagers.

cmurf 10y ago

As far as I've experienced on OS X, any running process does not survive logout. Granted it's a single session, and that session is also GUI. For a GUI login, I'd expect systemd to do exactly this. Right now, wayward processes ignore or just don't grok whatever "quit" notification the DE sends, and this will cause delayed restart/shutdown for 1m30s at which point systemd kills the user session. 1m30s is too long. Whereas on GUIless server, where I use tmux, the idea I'd login, run tmux and create a session or two, detach, logout, and by logging out all my tmux sessions go poof is not expected. But even in the cited thread there's a mechanism for such processes to get a separate user session.

wtbob 10y ago
> For a GUI login, I'd expect systemd to do exactly this. Processes have always done this when they receive a hangup (HUP) signal (unless they do something else, of course, but that's up to them). > But even in the cited thread there's a mechanism for such processes to get a separate user session. That mechanism has existed for decades: it's called nohup.

deleted 10y ago

[deleted]

digi_owl 10y ago

And now tmux is asked to accommodate the change. https://github.com/tmux/tmux/issues/428 https://github.com/tmux/tmux/issues/428