4 ms·

i don't see distros like debian ever using that as the default way, and there's no indication that the old way will disappear either.

catalogia 7y ago
I hope you're right, but Debian has adopted other questionable SystemD defaults in the past, such as killing nohup'd processes when the user logs out (which is absolutely inane.)
- api 7y ago
  What? I didn't even know about that. This stuff is such absolute trash.
  - catalogia 7y ago
    A lot of people (including me) learned about it the hard way when their tmux sessions began mysteriously disappearing. The solution is KillUserProcesses=no in /etc/systemd/logind.conf Some systemd advocates say the critics are just upset at change. I don't dislike change in general, but changing defaults out from under me? Defaults like this? That irks me. I lost a several tmux sessions before I realized what was happening. I thought I was doing something wrong because SystemD violated my expectations so severely.
    - loopz 7y ago
      Turns out some people like to force change upon others. They will always win out. These same people are oblivious to cause and effect.
      - deleted 7y ago
        [deleted]
    - yori 7y ago
      Why did the sessions disappear? Can you explain more about it?
      - fsh 7y ago
        Systemd can be configured to kill all processes belonging to a user when he or she closes the last login shell. Some people had this enabled on their servers and were surprised that their tmux/screen sessions kept disappearing.
        seabird 7y ago
        This is a bit disingenuous; people didn't just "have it enabled", it was made a default despite a lot of concern that it was such a radical departure from the normal behavior.
        fgonzag 7y ago
        Some people? Do you mean everyone who's distro did not change the default value?
    - api 7y ago
      A system-wide setting when the objective is user process control behavior? Really? Just wow.
      - kuschku 7y ago
        multi-user system, user logs out, do you want to have buggy software still hanging around? The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems).
        JohnFen 7y ago
        > multi-user system, user logs out, do you want to have buggy software still hanging around? Of course not. But I do want to have the nohup software they have running to keep running when they log out. > The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems). Right, which is why it should be possible to do this. The issue is that the default behavior has changed from honoring nohup to not honoring nohup. Defaulting to honoring nohup is what's expected, and is reasonable.
    - ColanR 7y ago
      I remember reading on HN at the time, how the systemD folks opened a bug report (or some such similar) on the tmux github because systemD was disappearing those tmux sessions, and their solution was for tmux to change how they managed persistency. Tmux stood their ground, and I think that's why KillUserProcesses=yes isn't still default. (iirc)
  - oarsinsync 7y ago
    It may have passed you by as it did me. It looks like either systemd or debian changed course and changed the default for KillUserProcesses to no.
- anonsivalley652 7y ago
  Hence the Devuan fork but now the Debian is "exploring alternatives" to supporting multiple init systems. https://lists.debian.org/debian-devel-announce/2019/12/msg00007.html https://lists.debian.org/debian-devel-announce/2019/12/msg00... My religious view, having started since the Slackware on CD days with original rc and experienced upstart, launchd, openrc, daemontools, runit, daemontools-encore and s6 is: SystemD does too much, has too many dependencies, does it awkwardly and is unfriendly to configuration management, robustness, troubleshooting, "least surprise" principle and simplicity. If I were Debian devs, there are two choices to init-agnosticism: a) pick one init provider at a time or b) manage multiple init systems simultaneously. For the latter, a very simple meta-init process could either exec() the only init system if one is used or supervise 2+ init systems. Then, there would need to be a tool to manage the lifecycle of a service no matter which init system it belonged to. It might be easier to pick a), but a common use-case is to use daemontools for custom or other services that need to be kept running. Granted, there are probably packages that already run daemontools, runit or daemontools-encore as a child under the existing system init. It's times like these that I wish there were a capabilities-oriented standard file layout such that every service knew how to start, soft-stop, hard-stop, enable, disable, reload-config and validate-config itself rather than every N init system having to find magic command-line args to not spawn in the background, change the user/group and change the log level, ports, bound address(es) and log destination. And then Cfengine, augeas, puppet, chef, salt, etc. reimplemented all of that logic per service. Services should also know how to backup/restore/wipe their own data (if not a 12Factor service themselves), whether they're up/down and how to gather their own metrics... and then cacti, nagios, nrpe and so on implemented all of that sort of logic per service too. sigh Cross-cutting concerns should be managed at the place that knows best how to manage the data and process lifecycle best: per service. Then, once that's done in a standard way, /etc configuration and configuration management can customize away. Having each service become enumerable and discoverable like a Bluetooth profile is another matter.
  - colechristensen 7y ago
    Systemd does something hard, easily arguably necessary, but it does not solve the problems well enough. I have similar feelings about containerization on Linux. I feel it comes down to lack of taste, or perhaps just the factioned nature of Linux distributions which are driven mostly by maintaining packaging instead of an operating system. Loo Experimenting with FreeBSD has been a breath of fresh air. Things I've come to expect to take an extended amount of time figuring out just work out of the box.

catalogia 7y ago

I hope you're right, but Debian has adopted other questionable SystemD defaults in the past, such as killing nohup'd processes when the user logs out (which is absolutely inane.)

api 7y ago
What? I didn't even know about that. This stuff is such absolute trash.
- catalogia 7y ago
  A lot of people (including me) learned about it the hard way when their tmux sessions began mysteriously disappearing. The solution is KillUserProcesses=no in /etc/systemd/logind.conf Some systemd advocates say the critics are just upset at change. I don't dislike change in general, but changing defaults out from under me? Defaults like this? That irks me. I lost a several tmux sessions before I realized what was happening. I thought I was doing something wrong because SystemD violated my expectations so severely.
  - loopz 7y ago
    Turns out some people like to force change upon others. They will always win out. These same people are oblivious to cause and effect.
    - deleted 7y ago
      [deleted]
  - yori 7y ago
    Why did the sessions disappear? Can you explain more about it?
    - fsh 7y ago
      Systemd can be configured to kill all processes belonging to a user when he or she closes the last login shell. Some people had this enabled on their servers and were surprised that their tmux/screen sessions kept disappearing.
      - seabird 7y ago
        This is a bit disingenuous; people didn't just "have it enabled", it was made a default despite a lot of concern that it was such a radical departure from the normal behavior.
      - fgonzag 7y ago
        Some people? Do you mean everyone who's distro did not change the default value?
  - api 7y ago
    A system-wide setting when the objective is user process control behavior? Really? Just wow.
    - kuschku 7y ago
      multi-user system, user logs out, do you want to have buggy software still hanging around? The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems).
      - JohnFen 7y ago
        > multi-user system, user logs out, do you want to have buggy software still hanging around? Of course not. But I do want to have the nohup software they have running to keep running when they log out. > The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems). Right, which is why it should be possible to do this. The issue is that the default behavior has changed from honoring nohup to not honoring nohup. Defaulting to honoring nohup is what's expected, and is reasonable.
  - ColanR 7y ago
    I remember reading on HN at the time, how the systemD folks opened a bug report (or some such similar) on the tmux github because systemD was disappearing those tmux sessions, and their solution was for tmux to change how they managed persistency. Tmux stood their ground, and I think that's why KillUserProcesses=yes isn't still default. (iirc)
- oarsinsync 7y ago
  It may have passed you by as it did me. It looks like either systemd or debian changed course and changed the default for KillUserProcesses to no.
anonsivalley652 7y ago
Hence the Devuan fork but now the Debian is "exploring alternatives" to supporting multiple init systems. https://lists.debian.org/debian-devel-announce/2019/12/msg00007.html https://lists.debian.org/debian-devel-announce/2019/12/msg00... My religious view, having started since the Slackware on CD days with original rc and experienced upstart, launchd, openrc, daemontools, runit, daemontools-encore and s6 is: SystemD does too much, has too many dependencies, does it awkwardly and is unfriendly to configuration management, robustness, troubleshooting, "least surprise" principle and simplicity. If I were Debian devs, there are two choices to init-agnosticism: a) pick one init provider at a time or b) manage multiple init systems simultaneously. For the latter, a very simple meta-init process could either exec() the only init system if one is used or supervise 2+ init systems. Then, there would need to be a tool to manage the lifecycle of a service no matter which init system it belonged to. It might be easier to pick a), but a common use-case is to use daemontools for custom or other services that need to be kept running. Granted, there are probably packages that already run daemontools, runit or daemontools-encore as a child under the existing system init. It's times like these that I wish there were a capabilities-oriented standard file layout such that every service knew how to start, soft-stop, hard-stop, enable, disable, reload-config and validate-config itself rather than every N init system having to find magic command-line args to not spawn in the background, change the user/group and change the log level, ports, bound address(es) and log destination. And then Cfengine, augeas, puppet, chef, salt, etc. reimplemented all of that logic per service. Services should also know how to backup/restore/wipe their own data (if not a 12Factor service themselves), whether they're up/down and how to gather their own metrics... and then cacti, nagios, nrpe and so on implemented all of that sort of logic per service too. sigh Cross-cutting concerns should be managed at the place that knows best how to manage the data and process lifecycle best: per service. Then, once that's done in a standard way, /etc configuration and configuration management can customize away. Having each service become enumerable and discoverable like a Bluetooth profile is another matter.
- colechristensen 7y ago
  Systemd does something hard, easily arguably necessary, but it does not solve the problems well enough. I have similar feelings about containerization on Linux. I feel it comes down to lack of taste, or perhaps just the factioned nature of Linux distributions which are driven mostly by maintaining packaging instead of an operating system. Loo Experimenting with FreeBSD has been a breath of fresh air. Things I've come to expect to take an extended amount of time figuring out just work out of the box.