7 ms·

Systemd seems great for servers and sysadmins. Does it's size, scope, and complexity actually do something for the grandmas of the world who use Linux? For that

Systemd seems great for servers and sysadmins. Does it's size, scope, and complexity actually do something for the grandmas of the world who use Linux? For that basic type of user, was the millions of lines of code and probably hundreds of thousands of hours of programmer's time worth it?

trynewideas 4y ago
Probably, since all of those users rely on services provided by servers managed by sysadmins. But it's such a misfit on desktop distros that the criticism there is valid and much louder. It never should've been a one-daemon-fits-all solution.
- dinosaurdynasty 4y ago
  systemd has never been a one-daemon-fits-all solution... it's dozens of daemons.
  - ykonstant 4y ago
    Collectively known as legiond-systemd.
josephcsible 4y ago
I'm a sysadmin for a medium-sized fleet of servers, and systemd definitely isn't great for me.
- aliqot 4y ago
  In what way?
  - josephcsible 4y ago
    It makes changes that break things (like suddenly kill -9'ing all of user's nohup and screen processes when they exited their SSH sessions, completely defeating the purpose of the tools) and replaces old simple ways of doing things with new complicated ways, without benefits of the new ways to justify the changes.
    - aliqot 4y ago
      > like suddenly kill -9'ing all of user's nohup and screen processes when they exited their SSH sessions This was surprising, I was unable to replicate it though. Did you set systemd to automatically clean up sessions? From the man page of logind.conf, KillUserProcesses= Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated.
      - josephcsible 4y ago
        That is what was doing it, but I didn't set it to do that. It was on by default when it was first released. Since then, the world realized how insane that was and major distros now turn it off for you.
      - kevin_b_er 4y ago
        The default is 'yes'. For awhile Fedora overrode it no, but then abandoned that: https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...
    - kaba0 4y ago
      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.
      - josephcsible 4y ago
        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.
  - traverseda 4y ago
    Very little locality of behavior. A service can appear in something like 8 different folders, can depend on stuff that is who knows where. It is just a not very elegant system, it's baroque and confusing where it doesn't need to be. The solution of course is more systemd. Instead of using generic Linux tools like grep, learn and remember a bunch of weird systemd-journald specific commands. Unfortunately I'm also a programmer, and only really have room in my head for one grep command, so it introduces frission and I have to look up the commands every time. Also just a lot of random breakage over the years.
    - kaba0 4y ago
      It’s almost like service management is a hard problem, and that shitty bash one-liner won’t solve anything correctly. It is basically a dependency manager, yet you are not replacing apt/pacman whatever with unix tools piped together, do you?
      - traverseda 4y ago
        It's a bit of a false choice to say the options are systemd or write everything in bash. Personally I do like OpenRC. Service management is a hard problem when you start adding things like socket activation, home directory management, DNS resolving, container management, log management, and whatever else they want to throw in. Now you might say "well DNS resolving isn't actually part of systemd, it's a seperate daemon", well they've been more and more tightly coupling all these different components together. Yes you can disable systemd's DNS resolver, but probably something else will break. They're all pretty tightly coupled together and they mostly seem to do that in a dumb way.

trynewideas 4y ago

Probably, since all of those users rely on services provided by servers managed by sysadmins. But it's such a misfit on desktop distros that the criticism there is valid and much louder. It never should've been a one-daemon-fits-all solution.

dinosaurdynasty 4y ago
systemd has never been a one-daemon-fits-all solution... it's dozens of daemons.
- ykonstant 4y ago
  Collectively known as legiond-systemd.

josephcsible 4y ago

I'm a sysadmin for a medium-sized fleet of servers, and systemd definitely isn't great for me.

aliqot 4y ago
In what way?
- josephcsible 4y ago
  It makes changes that break things (like suddenly kill -9'ing all of user's nohup and screen processes when they exited their SSH sessions, completely defeating the purpose of the tools) and replaces old simple ways of doing things with new complicated ways, without benefits of the new ways to justify the changes.
  - aliqot 4y ago
    > like suddenly kill -9'ing all of user's nohup and screen processes when they exited their SSH sessions This was surprising, I was unable to replicate it though. Did you set systemd to automatically clean up sessions? From the man page of logind.conf, KillUserProcesses= Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated.
    - josephcsible 4y ago
      That is what was doing it, but I didn't set it to do that. It was on by default when it was first released. Since then, the world realized how insane that was and major distros now turn it off for you.
    - kevin_b_er 4y ago
      The default is 'yes'. For awhile Fedora overrode it no, but then abandoned that: https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...
  - kaba0 4y ago
    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.
    - josephcsible 4y ago
      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.
- traverseda 4y ago
  Very little locality of behavior. A service can appear in something like 8 different folders, can depend on stuff that is who knows where. It is just a not very elegant system, it's baroque and confusing where it doesn't need to be. The solution of course is more systemd. Instead of using generic Linux tools like grep, learn and remember a bunch of weird systemd-journald specific commands. Unfortunately I'm also a programmer, and only really have room in my head for one grep command, so it introduces frission and I have to look up the commands every time. Also just a lot of random breakage over the years.
  - kaba0 4y ago
    It’s almost like service management is a hard problem, and that shitty bash one-liner won’t solve anything correctly. It is basically a dependency manager, yet you are not replacing apt/pacman whatever with unix tools piped together, do you?
    - traverseda 4y ago
      It's a bit of a false choice to say the options are systemd or write everything in bash. Personally I do like OpenRC. Service management is a hard problem when you start adding things like socket activation, home directory management, DNS resolving, container management, log management, and whatever else they want to throw in. Now you might say "well DNS resolving isn't actually part of systemd, it's a seperate daemon", well they've been more and more tightly coupling all these different components together. Yes you can disable systemd's DNS resolver, but probably something else will break. They're all pretty tightly coupled together and they mostly seem to do that in a dumb way.