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.
* 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.
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.
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.
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?
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.
> 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.
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
> 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.
> Believe it or not, that's actually the official slackware forum.
My bad. TIL.
> 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
Daemonizing processes has been a thing far before systemd even existed. Solutions similar to this "daemon" project are commonly employed in SysV init scripts. If anything, systemd made those things irrelevant by offering a more simple configuration to daemonize programs.
> The slackware solution requires starting those 3 processes
> On the other hand, the gentoo solution can start all 3 processes with just 1 .desktop files
It looks to me Gentoo doesn't start the other two processes. I don't see how "daemonize" or pkill is relevant here.
> 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.
With respect, this is a unsound take. The explanation is more simple and it's that Gentoo does not currently handle pipewire cleanup.
> * 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.
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.
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.
> 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…
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.
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.
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.
> 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?
>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.
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.