Honest question here: why do people hate systemd so much?
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.
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.
Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source
I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
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.
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.
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.
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.
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.
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.
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.
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 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...
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!
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.
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.
* 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.
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.
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.
Only relatively modern Debian versions. And even then, blame Debian, not systemd.
> 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
Firstly, umount “popping a warning” would break so many things, and then you really would have something to complain about. And if we really are talking about 30+ years ago, things have changed a lot since then, too. You used to stop and uninstall a service by finding its PID by running ”ps”, killing its process, and ”rm”-ing its files (and editing /etc/rc.local to remove the service’s startup line) But even before systemd, you would not dream of doing that anymore; you would run “invoke-rc.d thing stop”, or at least ”/etc/init.d/thing stop”, and use your package system to uninstall it. Those are new things since 30+ years ago.
> something has changed and it's causing me pain.
Consider quitting the technology business.
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.
Well, maybe. But what constitutes an “interactive tty”? Stdout or stdin? I’ve had problems where most things, including tty(1), tests stdin for TTY-ness, but if I’ve redirected stdout to a file I get all interactive questions to a file, and a pausing system waiting for input for a question not visible on screen.
> Having filesystems randomly mount themselves after you have deliberately unmounted them is actually dangerous.
The automounter, present in SunOS with NIS and NFS for 30 years, also does that, no?
> How about you consider having some manners?
Technology is constantly changing. Since your complaint was simply that technology has changed and is forcing you to learn something new, I think that’s an appropriate response. If you have more detailed complaints, those might be deserving of more respectful responses, but a “my 30 year old UNIX™ is changing and forcing me to learn new things, oh noes!” gets, and deserves, nothing better than a “git gud”.
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 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.
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.
>If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.