13 ms·

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd_kills_screen_and_tmux_by_default_on_logout/ https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to persist after the user logs out. (Well, it has other uses, but this is the main one IMO.) The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed. I don't know whether this situation is a problem with systemd or the distro, but it seems very much a problem with the culture summarised by the top commenter in the above thread, of (paraphrasing) glibly breaking existing workflows then casually brushing away criticism with arguments often boiling down to: "this is the right way, I don't care about tradition or protecting 'incorrect' usage."

zozbot234 6y ago
This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user session going when a program has been launched under nohup, instead it tightly couples its own "session" concept to the remote connection and then adds a totally ad-hoc, hacked-together feature called EnableLinger to somehow make nohup work anyway. It's amazing.
- pknopf 6y ago
  I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..
  - BeetleB 6y ago
    Gentoo is reaching out to you.
    - vpzom 6y ago
      Or if you don't want to go source-based, maybe Void or Alpine
  - edoceo 6y ago
    OpenRC, it's available on some Linux distros.
  - a-nikolaev 6y ago
    Void Linux, amazingly awesome distro.
    - dTal 6y ago
      Second this, an incredible distro with an impressive package manager.
      - pknopf 6y ago
        Except its maintainer recently quit.
        dTal 6y ago
        That's not accurate. There are many competent maintainers.
  - wrycoder 6y ago
    Devuan.org
    - kelnos 6y ago
      I still don't entirely get the point of Devuan. I put Debian buster on a low-RAM embedded box, and since systemd eats up precious RAM I'd rather keep, I just switched to OpenRC with apt install openrc && apt purge systemd If I needed it, Debian packages elogind as well. Rebooted and it worked perfectly. Now, I get that Debian doesn't really support OpenRC[0] (or sysvinit), and it could break in horrible ways when bullseye goes stable, or get removed entirely, but... I don't see why we need a fork before that happens? It seems like it's a lot of work to maintain a distro fork, when I feel like that effort could be more productively redirected to stronger maintenance and advocacy of OpenRC and/or sysvinit in Debian itself? [0] Debian's openrc package hasn't been updated in a little over a year, which is indeed concerning. sysvinit does seem to be more actively maintained, though.
- thristian 6y ago
  The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run runs inside it, and the system works. However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd: your browser, your chat program, your media player, all the miscellaneous helper processes they spawn, etc. Most people do want that stuff to be automatically shut down when they log out. Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons, systemd implements its own idea of "a login session" that works the way most people (who aren't experts on POSIX job control) expect.
  - zozbot234 6y ago
    > However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd Systemd's revamped notion of "session" includes graphical ones. Yes, that's different from the legacy sense of a mere text-terminal window. But since they've had to reimplement the whole concept of graphical sessions anyway, they could have made them work like textual ones. If you're not running a session manager as part of your windowed environment (almost everyone is these days) the whole thing might break, but then you can just enable the hacky "lingering" mode to make it work and you're no worse off than before.
  - lmm 6y ago
    > Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons This is a CADT attitude. Improving existing interfaces while maintaining compatibility is hard; it's also what makes the difference between a serious software professional and an incompetent vandal.
    - jka 6y ago
      'CADT' was new to me - noting my search findings, to save someone a little time: [redacted jwz domain]/doc/cadt.html (and yep, agreed, incremental safe progress towards a goal can be prone to disruption when people don't want to spend the time to consider existing use cases and the work required for gradual, graceful migration)
- pas 6y ago
  No, it has nothing to do with remote and such. systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup. cgroups are control groups, you know, to control processes. Which was simply missing for decades in Linux. nohup should be enhanced to support systemd, or systemd should provide a nohup wrapper, and just start a new scope (cgroup) for whatever the user launches with nohup. ... Now, that said, I have no idea why distros and systemd did what they did without much communication, but ... that's usually the Linux way :/
  - zozbot234 6y ago
    > systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup. Why should the user be concerned with how systemd happens to implement its session management. If you start a screen or tmux instance, it's unambiguous that you want that part of the session to persist after logoff and to be reachable upon logging on to the system again. That's what screen and tmux were designed to do.
    - pas 6y ago
      The user shouldn't be concerned. That's why the distro should solve this. But as we all know, abstractions are leaky, and encapsulation only goes so far. How should anyone know what the user really intends. When I start a tmux in a graphical session and click log out I want the system to stop my things completely, (almost) like I haven't even logged in. After all, my session never was set up to be an always-on server session thingie. The distro never advertised this, etc. Of course users who grew up on UNIX/POSIX/nohup and on distros that worked in a specific way (ie. without cleaning up processes after log out) expected this to continue. Debian made systemd default in Jessie, which was released in 2015, and it took 2 years for this subsection to appear there: https://wiki.debian.org/systemd#Orphaned_processes https://wiki.debian.org/systemd#Orphaned_processes It either did not bother that many people or no one really did anything to document/address it. Distros did not care apparently. systemd maintainers were aware that it breaks all and every double-forking self-backgrounding resident stuff, but they accepted the trade off, and even documented it: https://github.com/systemd/systemd/commit/65eb37f8fcf0c82db0d9b600bb804adf7ead0327 https://github.com/systemd/systemd/commit/65eb37f8fcf0c82db0...
yawaramin 6y ago
That thread also mentions the solution that will work: https://askubuntu.com/a/904125 https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen
- MereInterest 6y ago
  I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.
  - WesternStar 6y ago
    I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant. It is not obvious apriori that it is worthwhile to preserve existing conventions and not break existing code.
    - kimikimi 6y ago
      It's a good question and infects all of our software "sacred cows." The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things. Thus through repeated application of this approach the world of professional software development has aggregated itself into conformance to standards that barely make sense, are poorly specified, and have limited proof of concept, but tick whatever buzzword boxes are relevant to the immediate climate. If you want to take a real stand, invest yourself in "dead" technologies. Then you can choose whatever you want, and if other people want to follow you on it it's implicit that they are working on a similar problem, and not trying to play the platforms game(else they would be looking for an angle to "modernize")
dmurray 6y ago
Does nohup work? That's what I would expect to be the standard solution, as the Unix tool that "does this one thing and does it well".
- catalogia 6y ago
  No. SystemD defaults to breaking nohup, tmux, screen, emacs server, etc.
  - dooglius 6y ago
    You shouldn't be downvoted, this is correct. Sane distros will change the default.
    - throw0101a 6y ago
      > Sane distros will change the default. And sane developers don't break multi-decade behaviour in the first place.
  - fao_ 6y ago
    I'm not sure why you're getting downvoted when it's the stated position of the systemd developers that they default to breaking those things. They've acknowledged it publicly. Hell, there was even a thread on the exact issue with tmux 4 years ago: https://news.ycombinator.com/item?id=11797075 https://news.ycombinator.com/item?id=11797075 Top comment on that link: """Salient comment: "Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is: In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly. fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly.""" Or Nicholas Marriott's 9 year old as-yet unanswered questions to the systemd developers, that I copy from a post by hn user JdeBP: > "Shouldn't this code be part of glibc instead of tmux?" > -- Nicholas Marriott, 2011 > If you want to change how processes daemonize, why don't you change how > daemon() is implemented [...] ? > -- Nicholas Marriott, 2016 > * https://news.ycombinator.com/item?id=11798173 > * https://news.ycombinator.com/item?id=11798328 https://news.ycombinator.com/item?id=11798515 https://news.ycombinator.com/item?id=11798515
gerdesj 6y ago
Screen still works. I use it all the time. Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link you provide is absolutely huge and from three years ago. Please give me a simple "stages to reproduce ..." style report. Please keep it simple and short and I'll fill in the blanks if I can and only trouble you for stuff I'm too daft to work out.
- throw0101a 6y ago
  > Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-June/002624.html https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...
  - cmeacham98 6y ago
    This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think university, where students not logged in on a workstation should not be able to waste CPU), in other cases its a bad thing however (i.e. in yours). That means it must be configurable whether screen is considered an independent session or not.
    - throw0101a 6y ago
      Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.
      - Spivak 6y ago
        I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner. And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.
deleted 6y ago
[deleted]
oconnor663 6y ago
Have you tried `sudo loginctl enable-linger [username]`? This used to be well-documented, but I don't see much about it now. It's possible things have changed since the last time I had to deal with this?
- majewsky 6y ago
  What do you mean? I still see it in `man loginctl`. > enable-linger [USER...], disable-linger [USER...] > Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller. See also KillUserProcesses= setting in logind.conf(5).
  - oconnor663 6y ago
    Mainly I meant that I no longer see it recommended on the Arch wiki, which I think is where I first learned it. But it looks like that might be because Arch now compiles systemd with lingering on by default (or something similar to that, I'm probably using the wrong term).
    - majewsky 6y ago
      Linger does more than just keeping the session open after logout. It also means that the session gets started automatically on boot, which is necessary if you want to have systemd units for that user autostart. Case in point, the PulseAudio setup on my homeserver: https://github.com/majewsky/system-configuration/blob/2f93ff252f2f26c28862ed13cbf74e43617b83f1/hologram-damogran-audio.pkg.toml https://github.com/majewsky/system-configuration/blob/2f93ff...
thayne 6y ago
> The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed. Strange, KillUserProcess=no worked fine for me
- yrro 6y ago
  In addition I'm pretty sure every distribution ships with it disabled anyway.
  - thayne 6y ago
    Not Archlinux. But That's not surprising given arch's policy of keeping things as close to upstream as possible.
cyphax 6y ago
I read this comment, thought after having recently installed Debian replacing Slackware I'd wipe it again because that's unacceptable. So I ssh'd into the machine, started a screen session, detached it, killed ssh session, ssh back in and the session was still there. Is this an older problem? So far, after coming from Slackware, systemd hasn't been in the way so much, thankfully.
grandinj 6y ago
Given the insanely vitriolic level of personal criticism leveled at the systemd people on an ongoing basis, some degree of glibness is an unfortunate byproduct. How about we give them some benefit of the doubt, that they are mostly trying to make things better, and instead ask them "what is the technically correct way, in the systemd world, of implementing this functionality?" I suspect the answer, for screen, would probably require some degree of messing with the user manager daemon.
- ttctciyf 6y ago
  > "what is the technically correct way, in the systemd world, of implementing this functionality?" In the case of terminating programs left running in an ssh shell by a logged out user, it's a pretty simple answer IMO: just leave it alone - if the admin of the ssh server wants to terminate user processes on logout I think that's where the burden should lie and there's no good reason for systemd to get involved, that I can see.

zozbot234 6y ago

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user session going when a program has been launched under nohup, instead it tightly couples its own "session" concept to the remote connection and then adds a totally ad-hoc, hacked-together feature called EnableLinger to somehow make nohup work anyway. It's amazing.

pknopf 6y ago
I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..
- BeetleB 6y ago
  Gentoo is reaching out to you.
  - vpzom 6y ago
    Or if you don't want to go source-based, maybe Void or Alpine
- edoceo 6y ago
  OpenRC, it's available on some Linux distros.
- a-nikolaev 6y ago
  Void Linux, amazingly awesome distro.
  - dTal 6y ago
    Second this, an incredible distro with an impressive package manager.
    - pknopf 6y ago
      Except its maintainer recently quit.
      - dTal 6y ago
        That's not accurate. There are many competent maintainers.
- wrycoder 6y ago
  Devuan.org
  - kelnos 6y ago
    I still don't entirely get the point of Devuan. I put Debian buster on a low-RAM embedded box, and since systemd eats up precious RAM I'd rather keep, I just switched to OpenRC with apt install openrc && apt purge systemd If I needed it, Debian packages elogind as well. Rebooted and it worked perfectly. Now, I get that Debian doesn't really support OpenRC[0] (or sysvinit), and it could break in horrible ways when bullseye goes stable, or get removed entirely, but... I don't see why we need a fork before that happens? It seems like it's a lot of work to maintain a distro fork, when I feel like that effort could be more productively redirected to stronger maintenance and advocacy of OpenRC and/or sysvinit in Debian itself? [0] Debian's openrc package hasn't been updated in a little over a year, which is indeed concerning. sysvinit does seem to be more actively maintained, though.
thristian 6y ago
The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run runs inside it, and the system works. However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd: your browser, your chat program, your media player, all the miscellaneous helper processes they spawn, etc. Most people do want that stuff to be automatically shut down when they log out. Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons, systemd implements its own idea of "a login session" that works the way most people (who aren't experts on POSIX job control) expect.
- zozbot234 6y ago
  > However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd Systemd's revamped notion of "session" includes graphical ones. Yes, that's different from the legacy sense of a mere text-terminal window. But since they've had to reimplement the whole concept of graphical sessions anyway, they could have made them work like textual ones. If you're not running a session manager as part of your windowed environment (almost everyone is these days) the whole thing might break, but then you can just enable the hacky "lingering" mode to make it work and you're no worse off than before.
- lmm 6y ago
  > Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons This is a CADT attitude. Improving existing interfaces while maintaining compatibility is hard; it's also what makes the difference between a serious software professional and an incompetent vandal.
  - jka 6y ago
    'CADT' was new to me - noting my search findings, to save someone a little time: [redacted jwz domain]/doc/cadt.html (and yep, agreed, incremental safe progress towards a goal can be prone to disruption when people don't want to spend the time to consider existing use cases and the work required for gradual, graceful migration)
pas 6y ago
No, it has nothing to do with remote and such. systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup. cgroups are control groups, you know, to control processes. Which was simply missing for decades in Linux. nohup should be enhanced to support systemd, or systemd should provide a nohup wrapper, and just start a new scope (cgroup) for whatever the user launches with nohup. ... Now, that said, I have no idea why distros and systemd did what they did without much communication, but ... that's usually the Linux way :/
- zozbot234 6y ago
  > systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup. Why should the user be concerned with how systemd happens to implement its session management. If you start a screen or tmux instance, it's unambiguous that you want that part of the session to persist after logoff and to be reachable upon logging on to the system again. That's what screen and tmux were designed to do.
  - pas 6y ago
    The user shouldn't be concerned. That's why the distro should solve this. But as we all know, abstractions are leaky, and encapsulation only goes so far. How should anyone know what the user really intends. When I start a tmux in a graphical session and click log out I want the system to stop my things completely, (almost) like I haven't even logged in. After all, my session never was set up to be an always-on server session thingie. The distro never advertised this, etc. Of course users who grew up on UNIX/POSIX/nohup and on distros that worked in a specific way (ie. without cleaning up processes after log out) expected this to continue. Debian made systemd default in Jessie, which was released in 2015, and it took 2 years for this subsection to appear there: https://wiki.debian.org/systemd#Orphaned_processes https://wiki.debian.org/systemd#Orphaned_processes It either did not bother that many people or no one really did anything to document/address it. Distros did not care apparently. systemd maintainers were aware that it breaks all and every double-forking self-backgrounding resident stuff, but they accepted the trade off, and even documented it: https://github.com/systemd/systemd/commit/65eb37f8fcf0c82db0d9b600bb804adf7ead0327 https://github.com/systemd/systemd/commit/65eb37f8fcf0c82db0...

yawaramin 6y ago

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

MereInterest 6y ago
I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.
- WesternStar 6y ago
  I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant. It is not obvious apriori that it is worthwhile to preserve existing conventions and not break existing code.
  - kimikimi 6y ago
    It's a good question and infects all of our software "sacred cows." The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things. Thus through repeated application of this approach the world of professional software development has aggregated itself into conformance to standards that barely make sense, are poorly specified, and have limited proof of concept, but tick whatever buzzword boxes are relevant to the immediate climate. If you want to take a real stand, invest yourself in "dead" technologies. Then you can choose whatever you want, and if other people want to follow you on it it's implicit that they are working on a similar problem, and not trying to play the platforms game(else they would be looking for an angle to "modernize")

dmurray 6y ago

Does nohup work? That's what I would expect to be the standard solution, as the Unix tool that "does this one thing and does it well".

catalogia 6y ago
No. SystemD defaults to breaking nohup, tmux, screen, emacs server, etc.
- dooglius 6y ago
  You shouldn't be downvoted, this is correct. Sane distros will change the default.
  - throw0101a 6y ago
    > Sane distros will change the default. And sane developers don't break multi-decade behaviour in the first place.
- fao_ 6y ago
  I'm not sure why you're getting downvoted when it's the stated position of the systemd developers that they default to breaking those things. They've acknowledged it publicly. Hell, there was even a thread on the exact issue with tmux 4 years ago: https://news.ycombinator.com/item?id=11797075 https://news.ycombinator.com/item?id=11797075 Top comment on that link: """Salient comment: "Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is: In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly. fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly.""" Or Nicholas Marriott's 9 year old as-yet unanswered questions to the systemd developers, that I copy from a post by hn user JdeBP: > "Shouldn't this code be part of glibc instead of tmux?" > -- Nicholas Marriott, 2011 > If you want to change how processes daemonize, why don't you change how > daemon() is implemented [...] ? > -- Nicholas Marriott, 2016 > * https://news.ycombinator.com/item?id=11798173 > * https://news.ycombinator.com/item?id=11798328 https://news.ycombinator.com/item?id=11798515 https://news.ycombinator.com/item?id=11798515

gerdesj 6y ago

Screen still works. I use it all the time. Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link you provide is absolutely huge and from three years ago. Please give me a simple "stages to reproduce ..." style report. Please keep it simple and short and I'll fill in the blanks if I can and only trouble you for stuff I'm too daft to work out.

throw0101a 6y ago
> Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-June/002624.html https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...
- cmeacham98 6y ago
  This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think university, where students not logged in on a workstation should not be able to waste CPU), in other cases its a bad thing however (i.e. in yours). That means it must be configurable whether screen is considered an independent session or not.
  - throw0101a 6y ago
    Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.
    - Spivak 6y ago
      I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner. And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.

deleted 6y ago

[deleted]

oconnor663 6y ago

Have you tried `sudo loginctl enable-linger [username]`? This used to be well-documented, but I don't see much about it now. It's possible things have changed since the last time I had to deal with this?

majewsky 6y ago
What do you mean? I still see it in `man loginctl`. > enable-linger [USER...], disable-linger [USER...] > Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller. See also KillUserProcesses= setting in logind.conf(5).
- oconnor663 6y ago
  Mainly I meant that I no longer see it recommended on the Arch wiki, which I think is where I first learned it. But it looks like that might be because Arch now compiles systemd with lingering on by default (or something similar to that, I'm probably using the wrong term).
  - majewsky 6y ago
    Linger does more than just keeping the session open after logout. It also means that the session gets started automatically on boot, which is necessary if you want to have systemd units for that user autostart. Case in point, the PulseAudio setup on my homeserver: https://github.com/majewsky/system-configuration/blob/2f93ff252f2f26c28862ed13cbf74e43617b83f1/hologram-damogran-audio.pkg.toml https://github.com/majewsky/system-configuration/blob/2f93ff...

thayne 6y ago

> The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed. Strange, KillUserProcess=no worked fine for me

yrro 6y ago
In addition I'm pretty sure every distribution ships with it disabled anyway.
- thayne 6y ago
  Not Archlinux. But That's not surprising given arch's policy of keeping things as close to upstream as possible.

cyphax 6y ago

I read this comment, thought after having recently installed Debian replacing Slackware I'd wipe it again because that's unacceptable. So I ssh'd into the machine, started a screen session, detached it, killed ssh session, ssh back in and the session was still there. Is this an older problem? So far, after coming from Slackware, systemd hasn't been in the way so much, thankfully.

grandinj 6y ago

Given the insanely vitriolic level of personal criticism leveled at the systemd people on an ongoing basis, some degree of glibness is an unfortunate byproduct. How about we give them some benefit of the doubt, that they are mostly trying to make things better, and instead ask them "what is the technically correct way, in the systemd world, of implementing this functionality?" I suspect the answer, for screen, would probably require some degree of messing with the user manager daemon.

ttctciyf 6y ago
> "what is the technically correct way, in the systemd world, of implementing this functionality?" In the case of terminating programs left running in an ssh shell by a logged out user, it's a pretty simple answer IMO: just leave it alone - if the admin of the ssh server wants to terminate user processes on logout I think that's where the burden should lie and there's no good reason for systemd to get involved, that I can see.