2 ms·

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 i

by pas 7y 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 7y 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 7y 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...
  - zozbot234 7y ago
    > When I start a tmux in a graphical session and click log out I want the system to stop my things completely.[] The distro never advertised this, etc. The graphical environment could advertise that you have launched something that will persist upon disconnecting the session, and give you an option to terminate it entirely instead. (It's after all easier for graphical environments to offer these sorts of "user friendly" hints than for terminal-based workflows.)

by pas 7y ago

zozbot234 7y 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 7y 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...
- zozbot234 7y ago
  > When I start a tmux in a graphical session and click log out I want the system to stop my things completely.[] The distro never advertised this, etc. The graphical environment could advertise that you have launched something that will persist upon disconnecting the session, and give you an option to terminate it entirely instead. (It's after all easier for graphical environments to offer these sorts of "user friendly" hints than for terminal-based workflows.)