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.
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
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!
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.
Is the claim here that Red Hat is unnecessary coupling their critical parts of the distribution in ways that other distributions would not do? A few examples here would be nice.
Also, it's not just RedHat that's depending on systemd, as if its a conspiracy on their part.
https://www.theregister.com/2026/01/26/plasma_6_6_systemd_lo...
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.
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.
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.
I think it's true that it's an exhausting battle to keep all those parts independent when 95% of the devs/money agree it's better to integrate them. But it wouldn't be fair either for the 5% to put on the others the burden of keeping things independent because of their own preferences...
Yes, but this is hardly a unique systemd/Linux problem. I despise TypeScript for various reasons, always preferred vanilla JavaScript over TypeScript. So if I'm met with "Huh, this library is using TypeScript, am I ready to deal with that", I make the choice to not depend on that, even though half of the ecosystem uses TypeScript.
Going against the grain comes with more work probably, but this is also a choice we make, because we have strong feelings and opinions about something.
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
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
What about "systemctl --force --force poweroff" ?
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.
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?
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.
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.
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.
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.
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...
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.
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.
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 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.
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.
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.
* 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 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.
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.
The point of devuan is "we really do not like systemd". That's entire feature list
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.
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.
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.
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.
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.
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.
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.
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.
Yes and the systemd crowd wants to embrace and extinguish it as well [1]
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.
- daemontools
- openrc
- runit
- upstart
- insserv
- start-stop-daemonFine for 80s mainframes... not so great for modern laptops.
OpenRC does support parallel startup but for a desktop it's already fast enough without it - my whole Linux bootup sequence is faster than BIOS POST.
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 ?
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.
But I'm happily not using systemd and it's not something that causes me any particular trouble.
Even the defunct Upstart is better than what's in Devuan.
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.
having to manually deal with daemons was so painful, to the point of being exoteric.
* 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.
It is like the cult of "The UNIX Philosophy" hardly found in any commercial UNIX that spun out of AT&T UNIX System V.
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.
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.
Oh and "modern" is becoming more and more a pejorative for tech as far as I'm concerned.
Just through some random mess of unintegrated incomplete long abandoned half baked subsystems?
I really want to know, what do you use instead?
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.