I don't care: I can administer with relatively high confidence any Redhat- or Debian-derivate. Thanks to systems.
Most issues regarding systemd I encountered were due to a halfway adoption (Debian). Some things like timers are a bit more cumbersome than "the old way", but I wouldn't want to miss the added robustness. Most things systemd implements lead to _less_ issues. And writing a systemd unit is pretty easy, contrary to the old bash script mess.
So, no. Keep your Poettering-Bashing to yourself. I'd rather invest the time in geokking the systemd choices deeper.
In my job, I often release Linux services integrated with systemd and I like it more than the old init system.
My problems with systemd is the bloatware, not init related, that comes with it in modern Linux distributions.
In my perception systemd people doesn't respect the freedom of choice of the users, the right to simply switch off features they find useless, annoying or simply they don't want in their workflow for any reason. I have a personal wiki related to the preparation of the development server or PC I personally use and the large majority of the chapters are related to the systemd features I need or want to remove and often that is a pain. I would like to see the users' right to NOT use given secondary feature respected, giving them the capability to easily remove or disable them without side effects, for example, in the OS installer, to have the power to deselect features, having alternative options like "manual operation" (i.e. DNS, I should be able to disable the option opting for manual configuration using resolv.conf, just as example). Even better, the possibility to have an input configuration file with all your options so that them will be applied automatically during the installation.
IMHO, if all the distributions enforce the systemd way to do anything , we have a monopoly and monopolies are never good.
But why is there no such pushback agains linux kernel? What makes that monolith you cannot customize different enough from systemd? What if I don't want to use in-kernel usb stack, or audit, or key management, or LSM modules, or ELF binfmt support, or filesystems — you are forced by the distro to use all those features. Yet with systemd it's somehow different. I'm genuinely curious
For kernel, anyone is able to change flags and recompile and run it in a few mins. It is possible and well documented.
It's very much not the same situation for systemd.
So your point is distros provide dedicated tooling for simple recompiling of kernel (that is different from other distro packages), but do not have dedicated tooling for systemd? Fair point, but does not address the kernel being orders of magnitude bigger monolith than systemd.
Say you disabled LSM, rebuilt, now all stuff that requires Selinux does not work. Now what?
I haven't used Devuan for a while but I use another systemd-free distro and I think all such distros have benefited from work that Devuan has done to keep the option on the table.
I think you can even get my favorite init system on Devuan now - dinit. It has a simple and useful service file format that's trivial to use and it can monitor and restart processes and users can use it for starting up their daemons etc - BUT it doesn't take over the world and the log file formats are all text.
Love/hate systemd as I might, it's been rock solid everywhere I've used it, and I've used it heavily. It has it's quirks, as does the init-scripts that came before, and launchd on OSX (not sure what the modern equivalent is for MacOS).
However, the systemd journal raw format is binary data and would much rather a plain text log. All things being equal I'd rather deal with human readable files.
> However, the systemd journal raw format is binary data and would much rather a plain text log. All things being equal I'd rather deal with human readable files.
It happens to be worse than text logs, worse than just spewing JSON to files, and entirely worse than most binary log formats. Every log line takes several times it would under text, duplicates a ton of info (like writing boot id in every entry) and somehow is not crash-proof (at least every non-clean shutdown gets me journald complaining about corrupt log files).
It's also dog slow in commands that matter (well documented in systemd bugs on github).
It should be just sqlite with some strategic indexes and tables. It's so bad.
One feature of the Journal format which I don't believe to be a great design choice is that entries can contain non-unique fields. Unfortunately this doesn't seem to be something that is handled well by all tools, instead only returning the value for the first field of an entry with the provided name.
I'm probably in the minority for preferring journald's binary logging, especially alleviating the need for things like log-rotate, which I have always fought issues with. I like how RedHat distros have it setup, where journald collects the logs, but rsyslog is there parsing them into the traditional /var/log/messages and /var/log/secure, so you get some logs in plain text as well as being able to send them along to an rsyslog server the traditional way.
I haven't run into a situation with corrupt binary logs, and any crashed system I've booted with a rescue disk I can connect to the binary logs from the rescue distro's journalctl. That being said, I imagine one bad experience with a corrupt log or a non-booting system I can't get logs from would change my mind pretty quickly, but that hasn't been the case for almost a decade, so *shrug*
Personally I would much rather they had simply used an existing database file format. For example, sqlite3 which is robust and already present in the default installation of most Linux distributions. Querying system logs with SQL would be cool and make things a bit easier unlike the sd_journal API with it's strange/bizarre quirks.
You could write this. But you see the problem with systemd — because it integrates the journal with the init manager, it's hard to replace just one or the other.
Wow what an idea, that would work so well and give me a trivial way to build apps to do alerts, monitoring, shipping to remotes, and whatnot in virtually any language.
> However, the systemd journal raw format is binary data and would much rather a plain text log
Yeah, I also wish that at least was an option, would make some things easier.
Also wished the remote log sending was easier, not sure if it's just me but was a huge hassle to setup properly, and really hard to properly validate it works as expected in all cases. Finally got it working, but it isn't as easy as the other parts of systemd/journald.
It should have been an option, even dumb old CSV if it needed structured data. I didn't bother trying to natively ship and used promtail instead, to get it into Loki, so I could query via Grafana.
It seems though not having systemd in it would be against "init freedom": https://www.devuan.org/os/init-freedom . Or is there some particular criteria an init system needs to satisfy to be included, that systemd doesn't satisfy but the others do?
Their criterion for an init system to qualify for this so-called "init freedom" seems to be "not being systemd".
> Or is there some particular criteria an init system needs to satisfy to be included, that systemd doesn't satisfy but the others do?
Reading the first sentence on that page was to much?
"Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice."
systemd fails on the portability criteria.
Apart from that, why should they invest there limited time to include systemd? Devuan is Debian without systemd. If you want systemd install Debian.
they could've just cut out other systemd components (ntp, dns management etc) and use systemd
The point of devuan is "we really do not like systemd". That's entire feature list
Why provide systemd if devuan is just debian with systemd alternatives? What would be the point - if you want systemd use debian?
A systemd distro tends to be locked to systemd, with many pieces of software requiring systemd to be running. An init–freedom distro avoids such dependencies. Presumably, you can still install systemd if you really want to.
Yep, no "unnecessary entanglements" evidently (their words, not mine).
> Unnecessary entanglements
The problems with systemd are:
* that once it was adopted, every single package started requiring it
* which meant that packages that previously could run everywhere, now could only run on systemd-based systems
* binary logs - a solution that solved nothing but created problems
* which locked out any system that wasn't linux
* which locked out any linux system that didn't want to use it
* which led to abominations like systemd-resolved
* "bUt yOu DoNt hAVe tO uSE it" - tell that to the remote attestation crowd, of which Poettering is a founding member of. see https://news.ycombinator.com/item?id=46784572 - soon you'll have to use systemD because nothing else *can* be used.
The systemD developers don't care about any of this, of course. They've got a long history of breaking user space and poor dev practices because they're systemD. I mean, their attitude was so bad they got one of their principal devs kicked from the kernel because they overloaded the use of the kernel boot parameter "debug", which flooded the console, and refused to modify the debug option to something compatible like "systemd.debug", broke literally every other system, and then told everybody else "hey we're not wrong, the rest of the world is wrong." And this has been their attitude since then.
Look, if people want to use systemD, that's just fine. But it is a fact that the entire development process for systemD is predicated on making Linux incompatible with anything else, which is an entire inversion of how Linux and Free Software works.
I actually like unit files. But if systemD was just an init system, it would stop there.
I don't like unit files very much. Instead of these variables that are specific to systems, and are ignored if you use a too old version of systemd, thus running your ftp server as root, you can prepend to the command line: sudo -u nobody ftpd. This composes much better and you can use the same commands that work in the shell.
> * "bUt yOu DoNt hAVe tO uSE it" - tell that to the remote attestation crowd, of which Poettering is a founding member of. see https://news.ycombinator.com/item?id=46784572 - soon you'll have to use systemD because nothing else can be used.
You're saying that because the person who made systemd now work on hardware attestation, all Linux distributions will eventually require remote hardware attestation, where users don't actually have the keys?
Maybe I'm naive, maybe I trust my distribution too much (Arch btw), but I don't see that happening. Probably Ubuntu and some other more commercial OSes might, but we'll still have choices in what OS/distribution to use, so just "vote with your partitions" or whatever.
I think phones are a completely different beast though (and already a lost cause), PCs seems a lot more resilient to that sort of lock down.
But on the other hand, you might be right, you never know how the future looks. But personally I'll wait until there is at least some signal that it's moving in that direction, before I start prepping for it to actually happening.
In any such situation there's never going to be 100% acceptance by the losing side. Hence Devuan. Hooray - everyone gets a choice.
Honest question here: why do people hate systemd so much?
Many of us starting using Linux before systemd was a thing, and you get used to what you use, so when something new appears that are trying (well, in this case "tried and succeeded at") to replace a bunch of stuff, there is a natural push-back against it.
I think systemd also took a relatively non-unixy approach, where it's a big stack to adopt, rather than individual programs that work together well. Typically, we prefer the latter instead of the former, so some pushback is because of that too.
Initially i hated systemd for the change it bought and lennarts behavior, but today I'm wiser.
Today i hate systemd for its bad debugability (edit unit & daemon-reload loops), the lockups that happen whenever there is a fifo in the wrong place, and the processes that systemd spawns with no apparent related unit and without means to mask them. And the difficult to disable suspends on machines that never had any business suspending.
Could you please expand bit more about those processes that systemd spawns without units?
Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source
OK so those processes are launched not by systemd, but by dbus itself.
There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise.
There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know.
> I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.
It's that lack of visibility that still makes me low-key hate it, though it's no longer the part of the modern Linux ecosystem that I hate most so I mostly just accept that it's part of watching a platform I used to really like enshittenate itself.
Same here.
I started using Unix before Linux was a thing, and BSD-style rc scripts were a pain in the arse.
Then along came Linux with its sysvinit-style init scripts, which were a pain in the arse.
Now here's systemd with yet another form of init scripts, which are a pain in the arse.
Each time there's been an evolutionary shift in how we do things, and systemd works pretty well for the way we use desktop systems now. They're also not terrible for servers once you get used to them. I still find them pretty annoying.
Anyway the TL;DR is that computers suck and operating systems suck and init scripts suck and the whole thing sucks, and everything else we've tried is somehow worse than what we have.
It makes me want to just go back to fixing tractors. People are really grateful when you show up in the middle of a muddy field at 10pm and fix their tractor.
We should try runit. Too bad Debian relies on systemd...
Because "Stop Job Running For User 1001: (22s / 90s)" with no indication of which @$%^ing stop job it is is incredibly annoying. And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. And nondeterministic service initialization is absolutely Broken and Wrong.
It's.... fine, mostly. It solved no problems I had and introduced some minor ones I didn't, and offers significantly less visibility, but it's no longer the worst offender in those regards (hello, Wayland!) so I just write it off as another of the many ways the Linux experience has gotten worse over time.
> And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time.
we had tens of thousands of init scripts where we fixed that exact problem with init scripts that were delivered with distro. It's not systemd problem and if anything systemd made it better.
> And nondeterministic service initialization is absolutely Broken and Wrong.
if your dependencies are wrong but init system works you were just lucky.
If you gonna complain, complain about no option to tell machine to shut down in a given time interval which means "my UPS got 5 minutes left pls turn off" is unsolvable under systemd unless you go thru every single unit file in distro and override their timeouts.
I mean, 25 years ago I don't think any shop used the distro-supplied init scripts; those were just a skeleton you used to get the system into a state where you could edit them.
In the old time with init scripts you had to figure out where to put all those sleep(10) based on the servers specific hardware and software stack. Far from everything in the initi script blocked execution until they completely finished, and things that previously worked could suddenly stop working if you changed hardware or software.
The big difference that created deterministic servers in the past is that you could install the server once and then leave it for 10+ years without doing any updates. People were proud of servers and services with massive uptimes with no patches and no reboots. I only see those now if they either have no internet connection or are locked down containers with very restricted network access.
Init scripts were horrible
Here's a dinit service file for starting my bluetooth daemon:
type = process
command = /usr/lib/dinit/dbus-wait-for -s -f 4 -n org.bluez /usr/lib/bluetooth/bluetoothd
smooth-recovery = true
logfile = /var/log/dinit/bluetoothd.log
depends-on = dbus
depends-on = local.target
before = login.target
ready-notification = pipefd:4
There's no dodgy bash script behind all of this - it's C++ that just works - I can stop start, list and reload services with reliability.
I love it.
I mentioned it in the comment above. Commands that you run in a shell script do not always block execution until the underlying resources is fully available. If we take the network as an example, the script to open a vpn tunnel and providing the tap0 device may not be available for the next command to use just because you first run the network script, then start the vpn daemon, and then start the next daemon. What people did was to add a bunch of sleep(10) in hope that the tap0 was up by the end of the sleep, and this might had worked great for a few years until the admin added a few too many complex rules to the network daemon and now it need to be sleep(15) instead, but only on some days in the week. Everyone also knew (and ignored) that adding sleep in the initscript was a sign of bad design and extremely brittleness.
Debian did have a fairly good init builder that attempted to do some form of dependency ordering and trickery to get things done in the right order and in the right time, where you wrote a service-like configuration file and than rebuilt the initscript. The builder then compiled the configuration files into an generated shell script. Redhat did something similar if I recall right.
Manually editing the generated shell script was seen as both dodgy, brittle and dangerous given that it could be arbitrary changed by any installed package. Some packages also sed and awk directly at the generated init script.
e.g. Starting something in the background and having to stick sleep statements into the script to wait till it is ready to receive requests on whatever port it uses. The sleeps are fine on one machine and on another they aren't enough.
Stashing the PID somewhere and writing code to use the PID to work out if the process is still running and hasn't crashed so you can report a status on it. It's just a waste of one's own time doing this repeatedly and there are ways to do it badly. Every initscript repeated the work.
You could probably do something quite good with bash if you provided a library of functions and demanded that scripts be written to use them.
I think it's the brittleness. Tomorrow your ethernet adapter is enp4s1 instead of enp3s0 (because of systemd) so your rc script doesn't set up networking and you have to fix it.
Those that love it will fight for it. Those that hate it will simply avoid using it. There may be some commercial incentives for IBM/Redhat to push for it. Either way it will always be divisive for a myriad of reasons listed below. Some sysadmins will begrudgingly support it at work and some absolutely love to support it. I have supported it in the enterprise and I use it on gaming machines at home. (CachyOS / Bazzite). My daily drivers, servers both physical and VM will always be without it. (MX Linux / Void Linux / Alpine Linux).
I only use mini-PC's these days and all the games I play work great on CachyOS. All the other daily stuff works great on MX/Void and of course running firewalls, NAS and servers on Alpine is about as simple as it gets for me anyway. Bazzite on my laptop found my Brother laserjet instantly and without adding drivers.
- Some discussion on the matter [1a][1b][1c].
- Operating systems without systemd [2]
[1a] - https://unixdigest.com/articles/the-real-motivation-behind-s...
[1b] - https://nosystemd.org/
[1c] - https://without-systemd.org/wiki/index_php/Arguments_against...
[2] - https://without-systemd.org/wiki/index_php/Main_Page/
P.S. - One Windows machine left and I think it can sense what is coming...
Its a new thing to learn.
A lot of people like the do one thing well philosophy and systemd is intended to be an entire additional OS layer. People like systemd if they want more uniformity between distros.
The systemd developers are not exactly open to suggestions and criticism. Have a look through their issues!
In 2015, systemd was a giant, immature and complex galaxy of tools, that came to replace a hacky-but-mostly-stable bunch of shell scripts. It was pushed fast. It came with good ideas and innovations. It also came with security issues, bugs, and lost productivity.
The fact that the main guy behind the project has a very... abrasive personality, and that the project got to widespread adoption through political moves more than through technical superiority, turned that dislike into hate.
But it's 2025 now, systemd has stabilized now, and I don't really see the point of all this anymore.
That's the way open source works. The people that think there's a point go and fork and those that don't stay put.
Linux distros have become extremely complicated IMO. Systemd is not the worst example of this - the packaging systems are hard, things like SeLinux are very annoying. The stability is because companies have spent to make it so. There are enterprise features all over the place etc. This just isn't what all of us necessarily want. I think there's room for distros which can be understood at a technical level - which are composed of units that can be easily replaced that have defined functions.
The "my way or the highway" approach. Both how it works and how it was pushed.
For me, I guess several reasons:
* Log files aren't where I expect them. I can't just tail the right log file, I have to figure out a load of options to journalctl instead. Its defaults are annoyingly bad and I usually end up having to type long things to limit the range to something useful.
* The journal grows massively and is unbounded by default. Many times I set up a machine, and then it runs out of disk space. It's now instinctive for me to now check whether it's /var/log/journal that's using it all. In fact, I just double checked on the machine I happened to be using now, and the journal was 2.2GB.
* It's terribly documented, or at least not in the way that's familiar to older UNIX folks. It took me about 30 minutes of googling to figure out how to change the name recorded in the journal, which defaults to the command name in ExecStart (and so was really usefully just unshare in multiple of my services). For anyone that's wondering it's SyslogIdentifier - good luck finding that yourself. It makes sense, but it's woefully under documented anywhere.
* Whenever you change files that used to be the end of it, e.g. /etc/fstab, now you have to remember to `sysctl restart systemd-mount` - why can't whatever needs it just watch the file for changes instead?
* Too many things just happen in the background that never used to. Just now for instance, I manually unmounted a drive to resize2fs it because I wanted to move the underlying data. Between running e2fsck and resize2fs, systemd had already re-mounted it read/write. Luckily, resize2fs is smart enough to tell you. If I'd been doing the actual task using dd to copy the data elsewhere, I'd have ended up with a corrupted copy.
* Just yesterday, I discovered that edits under /etc/network/interfaces.d were just silently ignored, and I had to learn the new systemd way of doing it. I never did figure out how to set the MTU in the configuration either.
* The configuration files feels Windows-like and not UNIX-like
That said, I've reluctantly started creating systemd services instead of rolling my own init scripts, and it's quite nice not having to copy all the boilerplate from elsewhere and just having a handful of lines of config. But most of the time, I feel like I'm fighting systemd rather than working with it.
> The journal grows massively and is unbounded by default.
Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB.
> It took me about 30 minutes of googling
Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.
> Too many things just happen in the background that never used to.
The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service; run “systemctl stop srv-foo.mount” instead of just yanking out a file system from underneath the feet of any and all services which depended on that mount point.
> I never did figure out how to set the MTU in the configuration either.
“man systemd.directives”, search for “MTU”. Took maybe two seconds.
> Log files aren't where I expect them.
> I had to learn the new systemd way of doing it.
This, I strongly suspect, is your real problem.
> Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB.
I mean this probably depends on your distro. On Debian, it very much is saved to disk by default. And plenty of my 5GB VMs have in the past filled to 100% such that everything fails with write errors because the log files have consumed about 3GB.
> Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.
Again, fine if you know of the existence of that man page (I didn't) and know what option you're even looking for. Systemd always calls it journal as far as I knew, and doesn't use the syslog, so I didn't even think to google for syslog to change what I wanted.
> The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service
Thing is, it's all very well to say that, but it's downright dangerous to change the expectations that have held true for 30+ years without even a warning somewhere - e.g. running unmount popping warning "hey, we know you just asked for this to be unmounted, but we might just randomly remount it whenever because whatever you are doing is unimportant".
And this points to the root of the issue - UNIX has been following the UNIX way for over 3 decades. Suddenly, everything is changing, without any indication of things being different until stuff just doesn't work. This is exactly why people don't like systemd.
> > I had to learn the new systemd way of doing it. > This, I strongly suspect, is your real problem.
Absolutely.
I've got a zillion other things to do, without spending hours every time I upgrade to discover all the new ways systemd has come up with to ruin my life.
When I am forced to interact with systemd, it always slows me down unnecessarily, because the only reason I'm looking at it at all is because it's because something has changed and it's causing me pain.
No, I'll blame systemd. I've been using Debian for 25 years and we've only had systemd forced on us in the last maybe 5. OK, yeah, you're right. I'll blame Debian for forcing systemd on us, which is exactly the problem that Devuan is fixing.
Actually, I've been using SunOS and Solaris even longer than Debian. Putting scripts in /etc/init.d / /etc/rc.d isn't "new". It's been standard for at least 30 years. Actually, maybe making /etc/rc.d symlink to the /etc/init.d is early 2000s, I can't remember, but it's certainly not new.
But also, I've written many startup scripts in my time. And no, I absolutely wouldn't find its PID using ps and killing it. In my startup script, I'd save $! in a file, standardised in /var/lock for at least 20 years, and kill that.
And no, I wouldn't manually edit /etc/rc.local - because for decades it's run everything in /etc/rc*.d specifically to prevent the need to manually edit /etc/rc.local. None of this is new.
> umount “popping a warning” would break so many things
I mean, would it really? They've modified mount to pop up a warning to tell you that you manually changed /etc/fstab and what extra steps you need to do to placate systemd just to be able to mount your filesystem. Why can't unmount also do the same, e.g. gated on being run from an interactive tty? Having filesystems randomly mount themselves after you have deliberately unmounted them is actually dangerous.
> Consider quitting the technology business.
How about you consider having some manners?
Somebody responding to a question about why people don't like X with an explanation of how exactly X has changed their workflow for the worse doesn't mean that they should leave the technology business.
I'm sorry for you that your self-worth is so tied up in systemd that you can't bear to hear any criticism of it.
It was very rough the first few years. It's fine now.
If you don't use rust, i hate you, you should use rust, and i'll force rust on you
If you don't use systemd, i hate you, you should use systemd, and i'll force systemd on you
If you don't use wayland, i hate you, you should use wayland, and i'll force wayland on you
If you don't use gnome, i hate you, you should use gnome, and i'll force gnome on you
See the pattern?
I don't hate it but I certainly wish to avoid it for as long as possible.
I see no advantages over alternative modern init systems and a ton of disadvantages. I think it's bloated, even if you can disable much of it, I don't care for the binary log format, and I don't want to support something that is encouraging so much dependency and unnecessary inter-connectedness.
Not to mention it doesn't have the best security history.
In another sense, it seems like Windows at some of its worse. The very same people who used to bitch about the registry now advocate for systemd, which I think is kind of weird.
What's your favorite init system?
I use OpenRC because it's fine and works, I have no issues with it. It has limitations, from memory it can't do parallelization - I'm waiting for s6 to mature so it can work with Alpine, but that's current a work in progress, at least last I checked.
Ignoring the more stupid reasons why people dislike systemd; there's really only three reasons.
The first is just the simple fact that most people don't want to administer their distro as a hobby. Similarly, distro maintainers primarily care about shipping a complete package that they don't need to mess around with too much. Before systemd, every distro had its own bespoke choices in tools and utilities that were wired to work together. Systemd however effectively homogenized all those choices, since almost every major distro settled on systemd. The main difference between distros now is as a result not necessarily the choices the maintainers made, but things like the package manager and the release schedule, so there's less of an incentive to use other distro's. (This isn't some sort of conspiracy, which the dumber arguments against systemd tend to assume; it's just a case where systemd winds up as the easiest choice - systemd has Red Hat backing, wires complicated things together in a way where it works on most novel PC environments that usually require config fiddling when not using systemd and it's just one upstream maintainers have to submit bugs to rather than a ton of different ones. The reasons to pick systemd as opposed to "one million tools" mostly just comes down to systemd being less of a headache for maintainers.)
The second is that systemd violates some assumptions on how Linux software is "traditionally" designed. systemd is a PID 1 process, meaning it's job is to start every other process on the system. In regular Linux software design, this would be the only thing systemd does. Systemd does this, but it also provides a massive suite of services and tools for things that, historically, have been relegated to separate tools. It's a big bulky program, that while it is modular, is essentially competing with a bunch of other Linux utilities in ways that aren't really standardized. This combines with point 1, where distro maintainers near universally settled on systemd, and what happens is that a lot of non-systemd tools that do what systemd used to do aren't really being used anymore even though the systemd implementation isn't necessarily better.
Finally there is a legitimate, albeit niche, case to avoid systemd. Because it's massive and distro maintainers tend to enable a lot of things in systemd, using it means you're getting a lot of random background processes that use up CPU/memory. If you're constrained by that sort of thing, systemd becomes a pretty inefficient hulk of a program you need to tear out.
I do think a lot of the headaches involving systemd would be simplified if the Linux space had any sort of standardization on how to wire it's tooling together, but outside of the POSIX standard (which doesn't really cover this side of things; POSIX is mainly about userspace utilities and APIs, not "how should an OS's system services behave"), there isn't any. People have rose-tinted glasses about wiring together different tiny tools, when the reality is that it was usually a pain in the ass and reliant on config flags, outdated manpages and so on. Just look at the seemingly simple question of "how do I configure DNS on Linux" and the literal 5 different ways in which it can be set since the "standard" proved to be inefficient the moment things get even a little bit more complex than a single network device handling a single connection. (Which sounds like it'd be the case, but may I introduce the concept of wifi?) Systemd being a big program avoids a lot of these issues.
As my friend said:
>If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.
"Tricycle – Car Without Engine"
Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.
The thing is systemd really doesn't: the things people claim "shouldn't be in an init system" aren't - but there are systemd branded versions of a lot of basic facilities because you generally need something like them in a usable system.
And a lot of those utilities are just straight better then the alternatives, or at least make a decent practicality vs correctness trade off for desktop Linux.
systemd-cryptenroll for example is just straight up much easier to use for most applications of FDE, unless you're really doing network unlocking with something like Clevis.
No, one complaint (out of many) against SystemD is that it moves too much complexity into PID 0 which is a very special process on Linux that must not crash ever or the whole system goes down with it. The init system is one thing that SystemD insists on running under PID 0 even though it could be designed otherwise.
But PID 0 on Linux is the idle task…? Init is (usually) PID 1, PID 0 kinda just means that nothing is running on a given CPU (with caveats), also killing 0 has special meaning because well it's not a real process…
Nitpicking. Of course they meant PID 1.
Systemd seemd to be moving away from D-Bus and adopting varlink instead.
Which is like, D-Bus from Temu, if Temu was systemd. Is there anything they haven't NIH'd?
Varlink is everything that the usual systemd detractors should want; no binary formats, simpler mechanisms, based on stdout/stdin of processes.
Also, systemd did not create varlink, nor did they create D-Bus. They simply adopted them as the most suitable and established methods for IPC at the time.
Devuan is my go to if I need a mainline distro without systemd, but honestly I just use Alpine for everything, even my desktop. People have this idea that it's only for containers, but that isn't so - its package library has everything you could need well maintained. I like the tools better than void, and prefer the release model to that of Artix/Arch.
As a passionate systemd hater I still will not go back to using older bash-based initsystems and thus devuan.
I strongly believe that systemd brand is a worst thing that happened to Linux, hindering the spread and innovation in the Linux space, but at the same time I have to admit that systemd-as-pid1 is the best init system out there.
> hindering the spread and innovation in the Linux space
What "innovations" have been prevented or hindered by systemd? I guess you could argue "well, we can't know" but then what is the argument here really? I'm guessing there is something concrete your thinking about here, that systemd made impossible, but I'm not understanding what you're referencing, I can't recall anything like that.
alternate libc's like musl. the eglibc controversy showed this was necessary but poettering initially refused to support a "non-useful libc". his words.
But musl exists today? And even I use it from time to time, mostly I think in Alpine Linux. How was musl hindered if we can use it?
Maybe it isn't as popular as you would have wanted, but I don't think that's the same as claiming it's been hindered by systemd.
So if systemd refuses to support musl, it's "hindering the spread and innovation in the Linux space", and when they change their mind and work to add support for musl, it's "to embrace and extinguish it".
I got to line 1500 before I gave up, what from that indicates they want to "extinguish" musl?
> As a passionate systemd hater I still will not go back to using older bash-based initsystems and thus devuan.
Devuan lets you choose an init system so you do not have to use sys V init: https://www.devuan.org/os/init-freedom
A number of other distros also use init systems other than sysv init or systemd: Void, Alphine, etc.
The great thing is that there actually ARE options that are far better than init scripts and they don't have to be like systemd.
This is technically true. Problem is, they are way out of mainstream and thus are not really practical outside of niche applications like containers.
... or other niches like my laptops and desktops that I'm writing to you from.
I remember the time before systemd and there wasn't any innovation happening - everyone was content with hacky bash scripts.
Legible, discoverable, debuggable. They listed the commands the computer needed to run, in the order it needed to run them, to get the system running. It was absolutely beautiful. And then LSB came along and broke it, and as a result of that systemd now manages my home directory and cron tables. Shame, really.
> Legible, discoverable, debuggable.
When I first tried linux on the late 2000s, this was a major selling point. Something not working right? Oh neat I can actually investigate and fix or replace it instead of just having to live with it. Nowadays I'm not sure I'd see the advantage as a new user and may not bother even trying it out.
I could actually see systemd killing the whole year-of-linux-on-the-desktop thing not even because it's worse in any way, but because as time goes on the major distinguishing factors from other OSes are disappearing, so there's no longer reason for people to try it out.
Sure but not reliable, robust, integrated.
Fine for 80s mainframes... not so great for modern laptops.
You could install new hardware. Or worse — uninstall hardware.
Although that breaks systemd as well due to renaming all of your network interfaces because one Lennart Pottering continues to insist that desktop motherboards all work a certain way despite the evidence directly in front of his eyes.
Systems were simpler then and demands were lower. So what if the system boots sequentially and takes two days to boot up. But try to make it parallel and faster, and the whole house of scripts falls down or becomes illegible, undiscoverable and completely unmaintainable mess.
I wasn't talking about your system, I was talking about many systems everywhere. Just as an example, one of them may be powering your home internet and fast and reliable systemd boot is one of the reasons why multiple minutes had been saved on a hardware power cycle and service downtime.
Regardless of my opinion, this choice has been done by much more knowledgeable people and results are clear. Personally, I would pick a systemd distro any time over script init based.
Your memory is very selective. These service management tools are all older than systemd (and I'm sure there are plenty more):
- daemontools
- openrc
- runit
- upstart
- insserv
- start-stop-daemonThey didn't need to be hacky though. Clever wtfing in bash is a bad practice and has nothing to do with init systems.
There were other innovative systems - they just weren't adopted by the major distos - other than I think Ubuntu.
if other systems had actual good idea about how to do pid 1, they'd be used. Systemd despise its issues solved a lot of problems. There were many before but most just aimed to be slightly less shit sysv.
The problem of systemd was the fact Lennart Poettering is smartest person in the universe and why the smartest person in the universe would bother to listen to feedback of any lesser beings ?
> they'd be used
That's not how the world works. Oftentimes (most times) political decisions take place with zero or little merit.
> The problem of systemd was the fact Lennart Poettering
As I see it, his incredible arrogancy is the main source of the destructive vibe with systemd. He is actually the smartest person in this space, but paradoxically that doesn't make him right.
Other systems are getting used. They're just not getting adopted by the major distributions ...presumably because they've decided that conformity helps.
But I'm happily not using systemd and it's not something that causes me any particular trouble.
Always good to have options, but I'd personally never want to use a Linux without systemd.
I like Devuan because it matches the Linux I learned - people who learned with a Systemd distro might not like it as much.
I personally am very much happy that Linux is not like the Linux I learned. Slackware was an excellent learning experience and will always hold a dear place in my heart and memories, but not on any of my computers.
same. i still remember how painful it was to setup services without systemd.
having to manually deal with daemons was so painful, to the point of being exoteric.
The worst was editing an existing service for the distribution. With systemd you just need an override file, without, you have to patch the file and review it each time it is upgraded to check the differences.
Only if your config sucks at /etc/ management. But ultimately you change the default config then it's good to be notified when there are upstream changes to it so that you can decide for yourself if they are important/irrelevant/harmful for you and adapt your version accordingly.
Exoteric is the opposite of esoteric, which is the word you mean :)
I liked it coz I did remember the old ways (as in kernel 2.2.x old) and they fucking sucked. Few examples of bugs I had to fix in sysv that just can't happen in very simply written systemd unit:
* multiple java based apps wrote pid in java which meant few secs after JVM started, so calling start -> status made status return app is not running, which tripped some tools
* mysql wrote pid in /var/run which was (at that time, most moved it to tmpfs finally, and that is also easier with systemd) not removed on stop. and on start it only checked whether PID existed in system, not what the PID was. So sometimes if some other app happened to get same PID as mysql on previous boot, mysql would not start on boot
* there was no checks on whether stuff app needs is mounted so some volume failing to mount could make app start with empty dir and lead to a mess.
It has problems. But it's also a massive improvement.
I agree; I was there, too: <https://news.ycombinator.com/item?id=30312899>
I can use systemd but it's always annoying to configure and sometimes randomly breaks and it's hard to know why. init.d scripts are no better, though. Runit is quite cool.
runit is optional on Devuan.
Good for you, but I wish this attitude wasn't weaponised so frequently to prevent progress by people who actually want progress.
Debian without systemd is a good start. Now, do Debian without dpkg, and you may finally be getting somewhere.
The reason Debian fell to the systemd behemoth is because its sysvinit scripts were already a complete disaster. Slackware and Gentoo, on the other hand, were able to stay clear of the mess because they had a decent implementation to begin with.
And Sysvinit was never the only place Debian kept its mess.
Yeah, that's why Slackware and Gentoo have a much larger userbase than Debian :-D
Last time I checked, ChromeOS is a gentoo derivative that doesn't use systemd, so yes this but unironically.
Huh, TIL.
> ChromeOS (sometimes styled as chromeOS and formerly styled as Chrome OS) is a proprietary operating system designed and developed by Google. It is derived from the open-source ChromiumOS operating system (which itself is derived from Gentoo Linux)
It sort of makes sense. Gentoo is basically automated Linux From Scratch — you can make anything. It's like Yocto/OpenEmbedded but for PCs. It even uses the same language.
I use another distro but totally appreciate the effort to keep different branches of potential futures alive. Humans have a tendency, in tech and most other domains afaict, to put a lot of eggs in one basket because it's easier/allows-faster-moving-forward.. but that basket may have structural weaknesses that only shows once it has A LOT of eggs in it.
Yep, the Linux kernel comes to mind. There are niche alternatives but mostly everyone settles on Linux as their kernel because it's easier and allows moving faster forwards.
I have to admit to still having some philosophical discomfort over SystemD as I feel that it encompasses too much functionality. That said, it does work and that is probably the most important thing.
Linux (the kernel) has LOTS of functionality anyone barely use or even know. Without that, there's no tooling around this functionality, no adoption. Not even all TCP socket options (setsockopt) are documented!
Systemd pushed forward proper usage of capabilities, better watchdogs (in a broader sense, as systemd supports all kinds of them), isolation, policies, and so on and so forth. You need it all to efficiently control the daemons, and it's great when it's all available in a single suite.
Because of SystemD, you can't use Linux control groups. On systemd systems, only systemd is allowed to touch control groups. I think they even tried to make the kernel enforce this but they failed, so now it just breaks systemd if you do.
There are other things just work too.
So how do you configure it?
Just through some random mess of unintegrated incomplete long abandoned half baked subsystems?
I really want to know, what do you use instead?
A quick perusal of the site yields this page, which tells you what it uses by default: sysvinit.
https://www.devuan.org/os/init-freedom
It lists other options. It also lists other operating systems that don't use systemd.
I think what I hate most about systemd is that it has seemingly indoctrinated so many into believing that there are no viable alternatives, only some random mess of unintegrated incomplete long abandoned half-baked subsystems.
Why though? Systemd has been a huge success, dragging Linux kicking and screaming into the modern world.
It lacks the UNIX philosophy really. Binary logs are a sort of example of the attitude it has. That's why there has been kicking and screaming that you mention.
I have lots of 30-year old books on "Modern XXX" which makes you realise that the label is a bit meaningless. To put it another way, there are 30 year old operating systems with a much more "modern" design than Linux has...and we're not using them. It's not "modernity" per se that obviously tops the list of criteria or we'd be using something like BeOS or even Windows.
> It lacks the UNIX philosophy really.
The UNIX philosophy is not a golden rule or inherently good. Nor is it even really well defined (what is a "thing"?). SystemD does one thing and does it well - managing Linux systems.
> It's not "modernity" per se that obviously tops the list of criteria or we'd be using something like BeOS or even Windows.
Just because modernity isn't the only criteria for success doesn't mean it is irrelevant.
What you define as "one thing" is not seen as one thing by those of us that aren't systemd fans. That's all it is really.
Some people try to run Linux on Apple hardware, don't ask me, some people seem to be "technical masochists" :)
Most people don't like it when you drag them where they don't want to go and like it even less when you ignore that they "scream" about it. If system was universally positive no one would have to be dragged. This patronizing attitude of its developers and proponents is one of the main reasons why I avoid SystemD like the plague.
Oh and "modern" is becoming more and more a pejorative for tech as far as I'm concerned.
Indeed, as mentioned in another comment, all major UNIXes already had something similar in place.
never used this one but glad to see systemd free stuff. definitely interested to try thanks for sharin!
What is the newest laptop which can use S-states under Devuan? My 11-gen can not.
While other UNIX derived OSes have adopted similar systems before systemd was a thing, in Linux continues to be a drama.
It is like the cult of "The UNIX Philosophy" hardly found in any commercial UNIX that spun out of AT&T UNIX System V.
It should use some modern alternative, no old bash scripts.
Even the defunct Upstart is better than what's in Devuan.
who would use this?
Very resource constrained systems, systems where consistent admin between *BSD and Linux is important. Containers where you have reasons to break the single process practice.
Your phone. Haven't looked into Android images for at least a decade but it was just simple bash scripts back then.
My phone does not run Devuan.
People who hate idiots that put the verb before the noun.
My way or the highway. Classic RedHat (and GNOME, GTK, etc etc)
[dead]
That's good for you!
Isn't that a selfish view, though? "Works for me,so I don't care that systemd is creating dependencies everywhere for everyone else".
I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives.
Isn't linux about choice? It feels we're going on a downwards spiral where choice is being taken away from us in every domain
> I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives.
You can? The system where I'm writing this uses systemd, yet networking is handled by NetworkManager and not systemd-networkd. Time keeping is handled by chrony and not systemd-timesyncd (or whatever the systemd NTP client was called). Etc. Systemd in fact has many components that are optional. Of course, there are also parts of it that are non-optional, just like many other collections of related software.
> Isn't linux about choice?
Linux is "about choice" to the extent that the source code is freely available, and if you don't like what upstream is doing, you have the choice to fork it and do whatever you want. "Linux is about choice" does not extend to upstream maintainers being obligated to cater to every whim of every end user.
Case in point, Devuan: Not being satisfied with the path Debian was taking, they exercised their choice and are now doing their own thing. Good for them! And to the extent this has reduced the frequency of systemd haters starting yet another anti-systemd flame war on the Debian mailing lists, it seems to me Debian has won too. Hooray!
How is it someone's else's fault for that systemd has dependencies or that others depend on systemd?
If I use and like Firefox, and others depend on Firefox, or Firefox depend on others, then it's Firefox fault for you choosing Firefox?
I really don't understand the argument you're trying to make. You had choices before systemd, and you still have choices even though systemd is widespread, what's the problem? It isn't modular enough? Use something else then that is modular.
OK you're missing the historical context here. To make this story extremely short, the author of Systemd was already known for another project that was causing problems to Linux users but was shipped early. And when Systemd was released, it has several issues, too, so some distros like Debian withheld the switch. But at some point the folks at Red Hat decided to tie Systemd to the login mechanism for Gnome. I don't believe there was any hidden agenda here, it was just more logical for them. However, this caused huge headache for package maintainers of non-Systemd distros. There was the whole drama with voting, Debian project leader leaving, Devuan appearing and so on.
I believe most people moved on, but the way it was all done somehow didn't feel right.
The problem is mostly that programs started depending on aspects of systemd that are both very complex, and difficult/impossible to implement without ending up with systemd. Systemd's components don't play well with established standards (sometimes not running standalone at all), which contributes to the feeling of having to buy into the whole ecosystem just to use a small part of it, just for that one bit of a certain program that now depends on it.
This has happened with gnome's display manager, and now gnome-shell is threatening to cease functioning without systemd, as well as on systems that systemd doesn't run on such as the BSDs. KDE's new login manager is now doing the same, so in many respects, people's fears have been validated.
To be clear: systemd works fine to start/stop services. Usually. If you have a working system with systemd, it's rarely worth ripping out and replacing. That's just more risk than reward.
But that doesn't mean it's good.
No, I decided to include it to explain the emotional response to Systemd. I didn't mean to offend anyone. That stuff didn't work and broken things were pushed on people again, that's why some revolted.
PulseAudio never really got stable though, people switched to PipeWire so they wouldn't have to deal with it.
I don't think anyone would ever object against systemd as a project, it would make as much sense as objecting against, say, GNU Chess. All software has bugs, and they're gradually worked out. But the way it was introduced that made many people upset.
Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.
OpenBSD is a monolithic system with kernel and userspace developed together. Linux was a bazaar.
They do, they just want to whine about software other people made (that they don't contribute to) doing something they don't like.
Embrace extend extinguish tactics, now celebrated in Linux land.
Did anything else support cgroups V2?
Gnome, for example. GDM now needs systemd's userdb.
It is indeed becoming harder and harder to avoid and I understand that this isn't great, but systemd tackles some genuinely hard problems that others don't. Which is to say I don't begrudge Gnome devs for this and personally prefer systemd over current alternatives.
Dependencies may be becoming less properties of software, and more so properties of the distro's systemd wiring.
More and more software will assimilate systemd features. Free distros will patch, shim, emulate, flounder. Or in GPT parlance "Dependencies are no longer intrinsic properties of software; they are emergent properties of a distribution's systemd orchestration layer"
Meanwhile, gripes, fears etc,
'Linux' becomes interpreted vs inspectable.
Requires superfluous new literacy
Convolutes logs, tools Obscures causality
Centralized control above Unix process model
Fair well ps aux, hello systemctl, cgtop, gls
KILL (less lethalized) superceded, replaced by service stop and mask
Surrender chains for events, ie buggy debugging or complexity accretion
General obfuscation beneath the hood
Centralized ... indexed, logs vs text streams
And....
Upstream assumes systemd
Some resist
Costs rise
Optional becomes expected
Accidental incompatibility
And... systemd ingurgitates one by one, policy, supervision, logging, identity, dependency management and the rest of the world... digests it, and from the aether emerges a sweet smiley face, disgorging forth a monolithic mutant avatar, with Linux features.
I'll be quiet happy to be wrong about everything. Feel free to slaughter everything I've written. I don't even oppose systemd - I simply perceive it as a singularity that's drawing everything around me towards it. Wrong would definitely be good, so please don't hold back. I won't seek pardon for the rant though, because true or false, it's honest.
Edit: I was reading through my threads and thought the parent was asking me, though wasn't. I've unintentionally barged in here, but I'll leave the comment anyway, as it references a very big concern of mine.
If Google spends millions of dollars pushing Chrome on everyone, then it's their fault everyone is using Chrome.
With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
Want to run xterm? Requires Xorg. rootless Xorg requires udev, udev turned into a systemd component. want to run xterm without systemd? good luck, you are now the maintainer of your own LFS.
eudev was just a copy of the udev part of systemd, with some patches to build on musl, and work without systemd. All of that has been upstreamed now, LFS has instructions on how to build udev from the latest systemd release, without building systemd itself.
From the project documentation: "The xterm program is a terminal emulator for the X Window System." The application does not require xorg it requires an x11 server.
It just so happens that until recently xorg was the only game in town as far as Linux x11 servers are concerned.
xterm is literally x terminal but it's not systemd terminal
xterm runs on Wayland and arcan; you should pick a different strawman
Languages are confined. I don't speak Rust — yet — so when I want to modify some software that is written in Rust that is a disappointment. However, the effect of software being written in Rust is limited to that software and its libraries. It doesn't infect your system the way systemd does.
You can turn most parts off. Maybe don't talk about stuff you have not much idea about ?
There is point to complain about distros turning it on by default but you could have systemd where systemd just does unit management and not much more.
The hardest part to get rid of would probably be journald as this parasite's log format is just... not good in any metric but it isn't easy to replace either if you want to keep systemd functionality
You have the choice to use either Debian or Devuan.
One system to rule them all, blame any issue encountered on lake of full adoption, and label them as defamation. What could go wrong?
you can use and like and still complain about things that should be better or were better under old.
systemd solved a ton of headaches but also added few more, like inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.
> And writing a systemd unit is pretty easy, contrary to the old bash script mess.
We had thousands of lines of "simple" sysv init scripts fixes because apparently even seasoned maintainers or developers of the app can't figure it out. It's huge improvement.
One example: A java app that writes its own pid. The status subcommand relies on the pid existing.
so calling start then status will return that the service haven't started yet. And that is what stuff like for example Pacemaker does so it could just randomly fail under sysv. Under systemd it's all so much simpler
> inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.
What about "systemctl --force --force poweroff" ?
With two “--force” options, that is essentially equivalent to “echo o > /proc/sysrq-trigger”, isn’t it? I would think that one “--force” would have the actually desired effect.
Yes you're right.
You could do the same in a less invasive manner with daemontools like forever. Not only on Linux, but on BSD as well.
But people need a corporate and worse knockoff shoved down their throats, because DJ Bernstein is independent and we cannot have independent people in software.
I wrote a lot of daemontools wrappers and non-shell forking daemons.
Doing this is really, really error prone and fragile. Why the hell should I have to learn about double forking and PIDfe validation (and process groups and pty-or-not and all those other esoterica that daemontools still requires you to engage with if you want to do something outlandish like “run a program with a graphical component at boot”) just to make something run in the background?
You shouldn't. You should let it run in the foreground and let the system manager switch to the background before running it, if it wants to. This has many advantages, mostly simplicity.
I am not familiar with daemontools but I think it includes something similar to runit, which likes your processes to run in the foreground.
In daemontools' happy path, you're 100% right.
However, the happy path is very, very narrow. It breaks down as soon as you have to deal with:
- Set(e)uid daemons or any background service that needs to run as a different user than the one launching the service.
- Programs that report readiness somehow (the equivalent of the "notify" systemd type). Plenty of services won't crash when they should, so a standard for "it's all the way up" is useful.
- Start timeouts and failures. If daemontools is your only authority of the "status" result, recognizing a started-but-hung service is hard. Even if your service has some other "yes, the binary exists, but is it working?" check, getting daemontools+init to probe that and appropriately react to start timeouts can be fussy.
- Services that themselves spawn subprocesses (either forking or running separate child programs). Parent-process crashes are a recipe for orphaned things running and consuming resources/doing who knows what. You can solve this with a cgroup/namespacing/prctls to control orphan reparenting, but that's super hard to get right. Systemd has a one-liner for "on stop, kill this service and any program that was ever spawned in its tree". Having implemented the equivalent code to KillMode=control-group a in a few different "this has to be really reliable and bug-free" contexts now, having to manually manage this when managing services is a recipe for disaster. You'd think you know when your services will/won't have child processes, but you'd be wrong a lot (e.g. oddball JVM tracing sidecars, Pythons that always run a multiprocessing helper even if they don't use multiprocessing, Redis sometimes forking and doing bgsave, Erlang with its DNS-management child procs, literally anything ever written in Perl, Postgres, and so on. You would think that most managed child processes in big, mature software projects will know to kill themselves if their parent crashes for whatever reason. You would be wrong).
- Inter-service dependencies. Yes, many init systems take that on, but now you have the daemonization system and the init system--separate tools to configure, with overlap and expectations about each other.
- Race conditions around setting up pidfiles/locks when first deploying a service. Sure, once it's installed flock(2) will work fine, but what if you're installing a new distribution of the service and the installer picks a different lock directory from the one in use by the running service?
There are a lot more things I could list, but I'd rather not go back there. Having to manage this stuff by hand was a pretty low point for our field--as fully clued-in as sysadmins felt, we made a lot of mistakes, and made an environment that was deeply hostile to non-expert operators who just wanted to run a service and forget about it.
Systemd's far from perfect, but the challenges of doing this stuff with daemontools and friends weren't just "this is a worse implementation than systemd"; they were "this is existentially harder than using systemd precisely because it follows the 'unix philosophy' and maximizes control of (and thus responsibility for) an area where simple cases are often ... not".
Are you worried that you're going to become subject to attestation via systemd?
Only if you have no issue with the bloat of additional binary parsing of essentially text logs.
Text parsing isn't any better. There are many things wrong with systemd but this isn't a useful thing to get angry about.
Well said!