Systemd, ten years later: a historical and technical retrospective

Re:Systemd, ten years later: a historical and technical retr... by pas on Monday May 04, 2020 @08:08AM (#23066985)

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

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/65eb37f8fcf0c82db0...

[ Parent | on HN ]

Re:Systemd, ten years later: a historical and technical retr... by zozbot234 on Monday May 04, 2020 @08:27AM (#23067114)

> 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.)

[ Parent | on HN ]