Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They gave both a compile time and runtime configuration option to set the default behavior, package maintainers didn’t read the docs and shipped it incorrectly. I doubt systemd people are at fault here.

Plus, on a theoretical level that is the correct behavior, you don’t want to leave running processes gobbling up resources under a logged out user without explicitly allowing it.



Speaking as one of many who has lost work to the systemd-kills-your-processes issue: No, it's 100% systemd's fault. They shipped a change that broke nohup, screen, tmux, and a dozen other things. All of the feedback they've gotten about the process-killing feature has been negative, but their response has been to shut their ears and blame the problem on distros for not overriding their insane design decision.


The point of a default is that it's what a setting should be if you don't go out of your way to change it. The default was on, and you're faulting the distro maintainers for not changing it to off, when it should have just defaulted to off all along. (Or are you saying that it did default to off, and that the distro maintainers originally went out of their way to turn it back on? If so, that would surprise me, but I'd concede the point.)

Correct behavior is that a demonized process doesn't ever get killed just because another process in its original family tree dies.


> Correct behavior is that a demonized process doesn't ever get killed just because another process in its original family tree dies

Who decides what is a demonized process, vs one that just froze and won’t respond to some random UNIX convention, that can’t even reliably signal its state (what is tmux when it is frozen?)

So the solution is to explicitly specify that a given process wishes to live outside of the seat’s lifetime (either by specifying it as a service, which your earlier example ssh is on basically any distro, or by executing it as with systemd-run)


> explicitly specify that a given process wishes to live outside of the seat’s lifetime

Okay, so it does that now. But now how do you tell if it's frozen?


That’s not really the point, but there are of course plenty of ways for that (output, watchdogs, etc).

The point is that the OS does actually know “statically” that a given process is a daemon or not.


How is this random systemd convention better than a random UNIX convention though?


One is decidable the other can have false positives.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: