3 ms·

It solves a whole lot of problems to me. * It gets rid of a system cobbled together from init, inittab (which people rarely remember exists), monit, cron, and

It solves a whole lot of problems to me. * It gets rid of a system cobbled together from init, inittab (which people rarely remember exists), monit, cron, and inetd/xinetd. * It removes a bunch of horrible hacks in init scripts such as calls to sleep. * It removes the need for pid files. * It removes the need for a lot of stupid boilerplate, like the whole start-stop-daemon stuff in scripts. * It allows precisely tracking what belongs to each service. I can easily find out what a random process belongs to. * It captures all the log output of each process * It drastically improves the upgrade process -- I never need to look at a 3-way diff of /etc/init.d/apache2 again * As a developer it means I don't need to write a slightly different script for every distro * It makes logging a whole lot pleasant * It allows having user services without having to hack around it with cron * It allows a whole bunch of settings to be applied to any random service, without having to edit a shell script and figure out how to stick it in there. * It means services run identically when started by hand, without the confusion of a service inheriting my local environment. * It makes my VM servers boot faster. And if you're going to pipe up with "I reboot my servers once a year", that doesn't cut it for me. I boot my servers on demand, when they're needed. They adapt to the load.

ChuckMcM 5y ago
I had to chime in here and say I really like this post, thank you for taking the time to write it out. I would give it extra up votes if I could. It is a nicely concise summary of the problems. I'd disagree with the characterizations of the previous system as "cobbled" or "horrible hacks" but there are solid things that need to be solved well by any system initialization architecture/service.
- regularfry 5y ago
  For me the key idea is that they don't all need to be solved in the same place, by the same project. Implications that the systemd approach is the only way to do so really rub me up the wrong way.
  - kaba0 5y ago
    Which of these can be decoupled in your opinion, and isn’t very close to system init?
  - mariusor 5y ago
    Out of curiosity, what would you do if you had the inclination and the know how for solving all of these issues? Would you create a project for each of them or unite them under a single one like Lennart did?
throwdbaaway 5y ago
> It allows having user services without having to hack around it with cron Recently, I started using pipewire, which is designed to rely on a user-level service to start and stop the pipewire process. To bypass this requirement, the slackware guys came up with an elaborate solution that wraps the pipewire command with a daemonize tool that is supposed to cleanup after itself: https://www.linuxquestions.org/questions/slackware-14/using-pipewire-instead-of-pulseaudio-in-slackware-15-a-4175693980/ https://www.linuxquestions.org/questions/slackware-14/using-... Meanwhile, the gentoo guys just did the simplest thing possible: https://github.com/gentoo/gentoo/blob/f788f38/media-video/pipewire/files/pipewire-launcher.sh https://github.com/gentoo/gentoo/blob/f788f38/media-video/pi... Of course, with both of these workarounds, the semantic changes from "start this process once the user logs in" to "start this process once the desktop environment starts", but the end results are identical for almost all users.
- soraminazuki 5y ago
  > the slackware guys came up with an elaborate solution that wraps the pipewire command with a daemonize tool that is supposed to cleanup after itself You mean Slackware users on some random forum. Besides, the solution they came up with uses XDG autostart which has nothing to do with systemd. Not to mention that it's not even doing the exact same thing as the Gentoo solution and running two more commands in addition to pipewire. On top of that, Gentoo also seems to be using XDG autostart for Pipewire[1] so it's basically the same approach. [1]: https://github.com/gentoo/gentoo/blob/f788f389419678d2f2399eeb65fd2eedd7956196/media-video/pipewire/files/pipewire.desktop https://github.com/gentoo/gentoo/blob/f788f389419678d2f2399e...
  - throwdbaaway 5y ago
    > You mean Slackware users on some random forum. Believe it or not, that's actually the official slackware forum. And whatever solution those guys come up with, it will likely become the official solution. > Besides, the solution they came up with uses XDG autostart which has nothing to do with systemd. The slackware solution involves a project that nobody has heard of before, just so it can imitate the "user-level service" feature provided by systemd: https://github.com/raforg/daemon https://github.com/raforg/daemon > Not to mention that it's not even doing the exact same thing as the Gentoo solution and running two more commands in addition to pipewire. The slackware solution requires starting those 3 processes (pipewire, pipewire-media-session, pipewire-pulse) separately from 3 different .desktop files, likely because the daemon tool above can't properly reap the pipewire-pulse process (not sure whose fault is this though). On the other hand, the gentoo solution can start all 3 processes with just 1 .desktop files, because `pkill` takes care of it. Simple and effective. I think the key difference, in this case, is that the slackware guys are trying their best to imitate a systemd feature, while the gentoo guys seem to focus more on finding the best way to allow users to enjoy pipewire.
cout 5y ago
How much faster do your VM servers start with systemd? On the desktop, I feel like boot time is slightly longer than it was 20 years ago, yet hardware is faster now. I used to shut down my computer every night back then; now I leave it running, because it takes so long to get back to where I left off.
- deathanatos 5y ago
  > now I leave it running, because it takes so long to get back to where I left off. I think it takes my Linux system ~13 seconds to boot? That is definitely less time than it took 20 years ago, but I think that's mostly b/c the storage is no longer slow spinning rust running on IDE cables more than anything else…
  - iso1631 5y ago
    Returning to state is what takes time, not the boot process to login. It's Monday morning at 10:30, I've already got 29 tabs on 3 windows across 2 virtual desktops (2 monitors each) running on my main desktop. I've trimmed down to just 30 various rxvt windows with ssh or vim open, with files and notes at various stages of completion. Some tabs may restore next time I load my browser, some won't.
    - VortexDream 5y ago
      It's because of this that I've started to do everything in VMs. I can always save state and pick up where I left off without worrying about losing anything.
      - iso1631 5y ago
        Don't you have the same problem of having to reboot the VM occasionally?
- dale_glass 5y ago
  Haven't compared because I'd have to try SysV and see how much longer that takes. My current server boots in 10 seconds, which isn't bad.
arid_eden 5y ago
> * It drastically improves the upgrade process -- I never need to look at a 3-way diff of /etc/init.d/apache2 again lol. I had to trash an Arch Linux box because it failed to upgrade systemd from 208 to 211. Everytime I upgraded the system hung trying to mount filesystems so I had to roll back.
- kaba0 5y ago
  Perhaps arch broke something? How is it the failing of systemd without further verification??
- Spivak 5y ago
  You’re complaining about something different. If there’s a bug in systemd itself that makes your system unbootable then not much you can do except not upgrade. What the parent is talking about is the fact that services are organized into base service files and overrides. Base files live in /usr and are to be modified only by the package that owns them. Override files or full-replacements live in /etc which is for the local administrator. Service updates are now always a safe operation.

ChuckMcM 5y ago

I had to chime in here and say I really like this post, thank you for taking the time to write it out. I would give it extra up votes if I could. It is a nicely concise summary of the problems. I'd disagree with the characterizations of the previous system as "cobbled" or "horrible hacks" but there are solid things that need to be solved well by any system initialization architecture/service.

regularfry 5y ago
For me the key idea is that they don't all need to be solved in the same place, by the same project. Implications that the systemd approach is the only way to do so really rub me up the wrong way.
- kaba0 5y ago
  Which of these can be decoupled in your opinion, and isn’t very close to system init?
- mariusor 5y ago
  Out of curiosity, what would you do if you had the inclination and the know how for solving all of these issues? Would you create a project for each of them or unite them under a single one like Lennart did?

throwdbaaway 5y ago

> It allows having user services without having to hack around it with cron Recently, I started using pipewire, which is designed to rely on a user-level service to start and stop the pipewire process. To bypass this requirement, the slackware guys came up with an elaborate solution that wraps the pipewire command with a daemonize tool that is supposed to cleanup after itself: https://www.linuxquestions.org/questions/slackware-14/using-pipewire-instead-of-pulseaudio-in-slackware-15-a-4175693980/ https://www.linuxquestions.org/questions/slackware-14/using-... Meanwhile, the gentoo guys just did the simplest thing possible: https://github.com/gentoo/gentoo/blob/f788f38/media-video/pipewire/files/pipewire-launcher.sh https://github.com/gentoo/gentoo/blob/f788f38/media-video/pi... Of course, with both of these workarounds, the semantic changes from "start this process once the user logs in" to "start this process once the desktop environment starts", but the end results are identical for almost all users.

soraminazuki 5y ago
> the slackware guys came up with an elaborate solution that wraps the pipewire command with a daemonize tool that is supposed to cleanup after itself You mean Slackware users on some random forum. Besides, the solution they came up with uses XDG autostart which has nothing to do with systemd. Not to mention that it's not even doing the exact same thing as the Gentoo solution and running two more commands in addition to pipewire. On top of that, Gentoo also seems to be using XDG autostart for Pipewire[1] so it's basically the same approach. [1]: https://github.com/gentoo/gentoo/blob/f788f389419678d2f2399eeb65fd2eedd7956196/media-video/pipewire/files/pipewire.desktop https://github.com/gentoo/gentoo/blob/f788f389419678d2f2399e...
- throwdbaaway 5y ago
  > You mean Slackware users on some random forum. Believe it or not, that's actually the official slackware forum. And whatever solution those guys come up with, it will likely become the official solution. > Besides, the solution they came up with uses XDG autostart which has nothing to do with systemd. The slackware solution involves a project that nobody has heard of before, just so it can imitate the "user-level service" feature provided by systemd: https://github.com/raforg/daemon https://github.com/raforg/daemon > Not to mention that it's not even doing the exact same thing as the Gentoo solution and running two more commands in addition to pipewire. The slackware solution requires starting those 3 processes (pipewire, pipewire-media-session, pipewire-pulse) separately from 3 different .desktop files, likely because the daemon tool above can't properly reap the pipewire-pulse process (not sure whose fault is this though). On the other hand, the gentoo solution can start all 3 processes with just 1 .desktop files, because `pkill` takes care of it. Simple and effective. I think the key difference, in this case, is that the slackware guys are trying their best to imitate a systemd feature, while the gentoo guys seem to focus more on finding the best way to allow users to enjoy pipewire.

cout 5y ago

How much faster do your VM servers start with systemd? On the desktop, I feel like boot time is slightly longer than it was 20 years ago, yet hardware is faster now. I used to shut down my computer every night back then; now I leave it running, because it takes so long to get back to where I left off.

deathanatos 5y ago
> now I leave it running, because it takes so long to get back to where I left off. I think it takes my Linux system ~13 seconds to boot? That is definitely less time than it took 20 years ago, but I think that's mostly b/c the storage is no longer slow spinning rust running on IDE cables more than anything else…
- iso1631 5y ago
  Returning to state is what takes time, not the boot process to login. It's Monday morning at 10:30, I've already got 29 tabs on 3 windows across 2 virtual desktops (2 monitors each) running on my main desktop. I've trimmed down to just 30 various rxvt windows with ssh or vim open, with files and notes at various stages of completion. Some tabs may restore next time I load my browser, some won't.
  - VortexDream 5y ago
    It's because of this that I've started to do everything in VMs. I can always save state and pick up where I left off without worrying about losing anything.
    - iso1631 5y ago
      Don't you have the same problem of having to reboot the VM occasionally?
dale_glass 5y ago
Haven't compared because I'd have to try SysV and see how much longer that takes. My current server boots in 10 seconds, which isn't bad.

arid_eden 5y ago

> * It drastically improves the upgrade process -- I never need to look at a 3-way diff of /etc/init.d/apache2 again lol. I had to trash an Arch Linux box because it failed to upgrade systemd from 208 to 211. Everytime I upgraded the system hung trying to mount filesystems so I had to roll back.

kaba0 5y ago
Perhaps arch broke something? How is it the failing of systemd without further verification??
Spivak 5y ago
You’re complaining about something different. If there’s a bug in systemd itself that makes your system unbootable then not much you can do except not upgrade. What the parent is talking about is the fact that services are organized into base service files and overrides. Base files live in /usr and are to be modified only by the package that owns them. Override files or full-replacements live in /etc which is for the local administrator. Service updates are now always a safe operation.