4 ms·

My first experience with systemd was when they implemented a default that would kill processes when a user logs off. This may be acceptable in some single-user

My first experience with systemd was when they implemented a default that would kill processes when a user logs off. This may be acceptable in some single-user desktop environments, but it is absolutely unacceptable in any server environment. If I am using tmux, emacs --daemon, nohup, or any other custom program that catches SIGHUP, then it is inexcusable for systemd to escalate to sending SIGKILL. 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. I know that this default setting can be overridden at the distribution level, or at the system level. This doesn't matter, because it shows that systemd developers do not know how to choose appropriate defaults, and that any changes that are made in systemd need to be continually monitored for stupidity. Maybe this is just me being soured by a very poor first impression of systemd, but I haven't seen anything since to dissuade me from this impression.

macintux 7y ago
> ... they implemented a default that would kill processes when a user logs off Is that still the default? That’s horrific.
- thejsa 7y ago
  It doesn’t seem to do that on my Ubuntu 18.04 / 20.04 servers; I haven’t tried on desktop though as I don’t use Ubuntu there, would indeed be a huge violation of my expectations of how a system should work if so.
  - MereInterest 7y ago
    Most distributions have taken the sane route and changed this option at the distribution level. The point is more that any decisions systemd makes may be absolutely nuts, and need to be audited in detail by anybody choosing to use systemd. It is extra work that should never have been necessary, because systemd is untrustworthy.
- MereInterest 7y ago
  As of this thread [1] in January 2019, yes. The user poettering is Lennart Poettering, the original Creator and lead developer of systemd, and doesn't show any signs of coming to the light. At this point, my standard .bashrc includes a check of whether systemd is running, and whether this absurd setting is set, so at least I will get some warning, and can either fix it or complain to the sysadmin. [1] https://news.ycombinator.com/item?id=19023232 https://news.ycombinator.com/item?id=19023232

macintux 7y ago

> ... they implemented a default that would kill processes when a user logs off Is that still the default? That’s horrific.

thejsa 7y ago
It doesn’t seem to do that on my Ubuntu 18.04 / 20.04 servers; I haven’t tried on desktop though as I don’t use Ubuntu there, would indeed be a huge violation of my expectations of how a system should work if so.
- MereInterest 7y ago
  Most distributions have taken the sane route and changed this option at the distribution level. The point is more that any decisions systemd makes may be absolutely nuts, and need to be audited in detail by anybody choosing to use systemd. It is extra work that should never have been necessary, because systemd is untrustworthy.
MereInterest 7y ago
As of this thread [1] in January 2019, yes. The user poettering is Lennart Poettering, the original Creator and lead developer of systemd, and doesn't show any signs of coming to the light. At this point, my standard .bashrc includes a check of whether systemd is running, and whether this absurd setting is set, so at least I will get some warning, and can either fix it or complain to the sysadmin. [1] https://news.ycombinator.com/item?id=19023232 https://news.ycombinator.com/item?id=19023232