5 ms·

Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absol

Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absolutely _don't_ think that my init system should also be my bootloader. It also shouldn't manage my network configuration, or be responsible for controlling the system clock. And it shouldn't assert control of my home folders. And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago. My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project.

256 6y ago
> My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project. This could not be further from the truth.
- marios 6y ago
  At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux. What should have been done is fix the issue in whatever offending application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1]. [1] https://github.com/tmux/tmux/issues/428nk https://github.com/tmux/tmux/issues/428nk
  - majewsky 6y ago
    > At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want everything cleaned up after them unless they explicitly want something like screen or tmux to linger. > you need to do some insane things (IMO), like link tmux with libsystemd That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.
    - JdeBP 6y ago
      Now read https://news.ycombinator.com/item?id=11798458 https://news.ycombinator.com/item?id=11798458 .
    - marios 6y ago
      As pointed out by JdeBP, I confused RemainAfterExit= with KillUserProcess=. RemainAfterExit is an option indicating how systemd should process a unit file, while KillUserProcess is for systemd itself. It's nice to know that libsystemd is not required in all cases, but I still have a problem with software having to be modified because systemd changes how libc's daemon() function behaves.
  - JdeBP 6y ago
    You have wildly mis-spelled "KillUserProcesses". * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
    - marios 6y ago
      yes, indeed. Too late to edit now though :(
deleted 6y ago
[deleted]
dralley 6y ago
>I absolutely _don't_ think that my init system should also be my bootloader. Good thing it's not? systemd-boot is an entirely different binary, it's not even installed by default by any large distro I know of. The only commonality between them is that they are developed under the same broad project umbrella, just like "cp" and "ls" and "cat" are all part of the GNU coreutils umbrella. This is a theme for an entire class of incorrect complaints about systemd -- the misconception that just because a tool is called systemd-$thing means it's part of the systemd init system, rather than "a tool developed by the systemd project".
ac29 6y ago
So dont use it all? I dont, and would have to go out of my way to use some of it. It's like saying you don't like GNOME because you don't like it's PDF viewer. The best thing about Linux is that you are free to pick and choose even low level components of the system as much as you'd like.
robocat 6y ago
> And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago. gnome-shell used by the Gnome/Ubuntu login process also depends upon evolution-data-server!! See `apt-cache depends gnome-shell` for other dependencies... Debian chose systemd instead of upstart because of licensing, not features, according to https://wiki.debian.org/Debate/initsystem/upstart https://wiki.debian.org/Debate/initsystem/upstart
- JdeBP 6y ago
  If you have only read the wiki pages, written to summarize arguments by their various proponents, then you do not know why Debian people made this choice. The wiki pages do not relate that. Start by reading Debian bug #727708 in its entirety.
- robocat 6y ago
  https://blog.darknedgy.net/technology/2020/05/02/0/ https://blog.darknedgy.net/technology/2020/05/02/0/
marios 6y ago
I have a problem with how service files are good, except when you don't get them right on the first try and it's difficult to debug (unless I've missed something obvious). More generally, I find that systemd is difficult to observe and thus debug. To debug an ancient init.d script, you'd just run it with "sh -x" rather that sh, and you would have a trace of what the script is doing. If your service file is a tad more complicated, then you quickly discover that there's a scripting language masquerading behind key/value entries. I have a hard time wrapping my head around dbus being the core component used for coordination among systemd components. dbus wasn't built for this use case, and having PID1 depend on a well behaved dbus for proper system operation sounds insane. systemd adds a lot of features, which means additional complexity. My understanding so far is that the tooling is not there yet to manage this complexity. Another gripe I have with systemd is that it does parallel service start introduces non determinism at boot. Which means your setup could work very well most of time, but fail miserably 1 time out of 10. Not exactly what you'd want if you are rebooting a remote server for example. s6 [1] init doesn't appear to have this problem. [1] https://skarnet.org/software/s6/ https://skarnet.org/software/s6/

256 6y ago

> My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project. This could not be further from the truth.

marios 6y ago
At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux. What should have been done is fix the issue in whatever offending application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1]. [1] https://github.com/tmux/tmux/issues/428nk https://github.com/tmux/tmux/issues/428nk
- majewsky 6y ago
  > At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want everything cleaned up after them unless they explicitly want something like screen or tmux to linger. > you need to do some insane things (IMO), like link tmux with libsystemd That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.
  - JdeBP 6y ago
    Now read https://news.ycombinator.com/item?id=11798458 https://news.ycombinator.com/item?id=11798458 .
  - marios 6y ago
    As pointed out by JdeBP, I confused RemainAfterExit= with KillUserProcess=. RemainAfterExit is an option indicating how systemd should process a unit file, while KillUserProcess is for systemd itself. It's nice to know that libsystemd is not required in all cases, but I still have a problem with software having to be modified because systemd changes how libc's daemon() function behaves.
- JdeBP 6y ago
  You have wildly mis-spelled "KillUserProcesses". * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
  - marios 6y ago
    yes, indeed. Too late to edit now though :(

deleted 6y ago

[deleted]

dralley 6y ago

>I absolutely _don't_ think that my init system should also be my bootloader. Good thing it's not? systemd-boot is an entirely different binary, it's not even installed by default by any large distro I know of. The only commonality between them is that they are developed under the same broad project umbrella, just like "cp" and "ls" and "cat" are all part of the GNU coreutils umbrella. This is a theme for an entire class of incorrect complaints about systemd -- the misconception that just because a tool is called systemd-$thing means it's part of the systemd init system, rather than "a tool developed by the systemd project".

ac29 6y ago

So dont use it all? I dont, and would have to go out of my way to use some of it. It's like saying you don't like GNOME because you don't like it's PDF viewer. The best thing about Linux is that you are free to pick and choose even low level components of the system as much as you'd like.

robocat 6y ago

> And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago. gnome-shell used by the Gnome/Ubuntu login process also depends upon evolution-data-server!! See `apt-cache depends gnome-shell` for other dependencies... Debian chose systemd instead of upstart because of licensing, not features, according to https://wiki.debian.org/Debate/initsystem/upstart https://wiki.debian.org/Debate/initsystem/upstart

JdeBP 6y ago
If you have only read the wiki pages, written to summarize arguments by their various proponents, then you do not know why Debian people made this choice. The wiki pages do not relate that. Start by reading Debian bug #727708 in its entirety.
robocat 6y ago
https://blog.darknedgy.net/technology/2020/05/02/0/ https://blog.darknedgy.net/technology/2020/05/02/0/

marios 6y ago

I have a problem with how service files are good, except when you don't get them right on the first try and it's difficult to debug (unless I've missed something obvious). More generally, I find that systemd is difficult to observe and thus debug. To debug an ancient init.d script, you'd just run it with "sh -x" rather that sh, and you would have a trace of what the script is doing. If your service file is a tad more complicated, then you quickly discover that there's a scripting language masquerading behind key/value entries. I have a hard time wrapping my head around dbus being the core component used for coordination among systemd components. dbus wasn't built for this use case, and having PID1 depend on a well behaved dbus for proper system operation sounds insane. systemd adds a lot of features, which means additional complexity. My understanding so far is that the tooling is not there yet to manage this complexity. Another gripe I have with systemd is that it does parallel service start introduces non determinism at boot. Which means your setup could work very well most of time, but fail miserably 1 time out of 10. Not exactly what you'd want if you are rebooting a remote server for example. s6 [1] init doesn't appear to have this problem. [1] https://skarnet.org/software/s6/ https://skarnet.org/software/s6/