5 ms·

Okay, I'll admit I was hoping for a blank web page :-). Not a fan. I always ask ""What problem is this trying to solve?" and then "Is this a good solution for

Okay, I'll admit I was hoping for a blank web page :-). Not a fan. I always ask ""What problem is this trying to solve?" and then "Is this a good solution for that?" I appreciate the "startup dependency problem" and when I was in the Systems Group at Sun we worked with AT&T on their solution which was the whole "run level" thing. And I appreciate the whole "shell scripts can do anything" problem that just using a naming scheme on shell scripts to run can lead to unexpected behaviors. From an architectural taste perspective, I prefer systems which are more comprehensible in parts and thus don't try to abstract out semantics to the point of incomprehension. So at the end of the day, something with a better model, better visibility into its operation and configuration, with a way to validate and debug dependencies would be good. But I haven't been impressed with systemd.

dale_glass 5y ago
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.
Arch-TK 5y ago
>I appreciate the "startup dependency problem" - except systemd doesn't actually solve this problem. Good to see people down-voting a completely factually correct statement that they don't believe and don't want to personally investigate. Go read the systemd sources or read any article analyzing how systemd does dependency based startup and see for yourself.
addicted 5y ago
SystemD solved enough problems that such a large number of distro owners switched to it that one of the biggest complains against it is how prevalent it is.
mtzet 5y ago
> when I was in the Systems Group at Sun we worked with AT&T on their solution which was the whole "run level" thing Interesting that you mention Sun. Didn't SMF precisely replace runlevels with SMF milestones[1] in much the same way systemd replaces runlevels with target units? [1] https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunlevels-13026.html https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunleve...

dale_glass 5y ago

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.

Arch-TK 5y ago

>I appreciate the "startup dependency problem" - except systemd doesn't actually solve this problem. Good to see people down-voting a completely factually correct statement that they don't believe and don't want to personally investigate. Go read the systemd sources or read any article analyzing how systemd does dependency based startup and see for yourself.

addicted 5y ago

SystemD solved enough problems that such a large number of distro owners switched to it that one of the biggest complains against it is how prevalent it is.

mtzet 5y ago

> when I was in the Systems Group at Sun we worked with AT&T on their solution which was the whole "run level" thing Interesting that you mention Sun. Didn't SMF precisely replace runlevels with SMF milestones[1] in much the same way systemd replaces runlevels with target units? [1] https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunlevels-13026.html https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunleve...