SystemD is blamed for long boot times and being heavy and bloated on resources. I tried OpenRC and Runit on real hardware (Ryzen 5000-series laptop) for week each and saw only 1 second faster boot time.
I’m old enough to remember plymouth.service (graphical image) being the most slowest service on boot in Ubuntu 16.04 and 18.04. But I don’t see that as an issue anymore. I don’t have a graphical systemD boot on my Arch but I installed Fedora Sericea and it actually boots faster than my Arch despite the plymouth (or whatever they call it nowadays).
My 2 questions:
- Is the current SystemD rant derived from years ago (while they’ve improved a lot)?
- Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?
Nah, it’s fine. Boot times are considerably faster than sys.v in most cases, and it has a huge amount of functionality. Most people I work with have adopted it and much prefer it to the old init.d and sys.v systems.
People’s problem with systemd (and there are fewer people strongly against it than before) seem to break down into two groups:
-
They were happy with sys.v and didn’t like change. Some were unhappy with how distros adopted it. (The debian wars in particular were really quite vicious)
-
It does too much. systemd is modular, but even so does break one of the core linux tenets - “do one thing well”. Despite the modularity, it’s easy to see it as monolithic.
But regardless of feelings, systemd has achieved what it set out to do and is the defacto choice for the vast majority of distros, and they adopted it because it’s better. Nobody really cares if a user tries to make a point by not using it any more, they’re just isolating themselves. The battle was fought and systemd won it.
“do one thing well”
Arguably, Systemd does exactly that: orchestrate the parallel starting of services, and do it well.
The problem with init.d and sys.v is they were not designed for multi-core systems where multiple services can start at once, and had no concept of which service depended on which, other than a lineal “this before that”. Over the years, they got extended with very dirty hacks and tons of support functions that were not consistent between distributions, and still barely functional.
Systemd cleaned all of that up, added parallel starting taking into account service dependencies, which meant adding an enhanced journaling system to pull status responses from multiple services at once, same for pulling device updates, and security and isolation configs.
It’s really the minimum that can be done (well) for a parallel start system.
I like it too. Very easy to work with and set up services as needed.
I just hate the syntax, systemctl start apache2 feels like dumb manager speak over service apache2 start.
But other then that I love how systemd has been for me.
How so? I like the systemctl syntax more, since it allows for starting/stopping many units at once. It also supports a much richer set of commons than service ever did.
it just feels like a manager decided the command should read like english, made the decision then went back to never entering a command again in the terminal again. every day, i get to decide, should i enter “systemctl restart problem_service” all again or hit up on the keyboard and and hold back, then rewrite over the previous status command. bit less work if the status/stop/start/restart bit was on the end like it used to be.
In BASH ALT+T will swap the last white spaced separated strings… It’s still annoying but makes “systemctl problem_server start/status/restart” a bit easier. CTRL+W will clear the current string to whitespace, so up arrow, ALT+T, CTRL+W, status, ALT+T, Enter.
The bit was on the end because it was an argument to the script specific to that program. Instead, the control is now at the start because it is an argument to systemctl itself. This removes the ability to define custom controls, but enables you to control many things at once.
Yeah,
command subcommand args.... Theserviceformat makes more sense when you’re seeing it as “run this script to control this service”. Thesystemctlformat makes more sense as a frontend subcommand to control systemd itself.
systemctl start apache2 mysql haproxy
That is the reason.
Y’know, I felt that way to begin with and it certainly took a long time for my fingers to adjust, but I’ve grown to adjust to that.
And it’s better - you can do: “systemctl restart Service1 Service2 Service3” Before, with “system Service1 restart” you could only action on service at a time.
Plus, it’s linux, so you can set up aliases to change the order into anything you like, even carry on using the old muscle memory formats. (Although I don’t encourage this if you intend working on multiple servers!)
Is there somewhere I can read about the Debian wars? I am curious about that 🤓
I also think that sounds intriguing.
Thanks a lot. I truly hope this is the big picture and SystemD whiners are just a fringe minority lol
systemd is modular, but even so does break one of the core linux tenets - “do one thing well”.
Linux itself (i.e. the kernel) breaks the hell out of that so-called core tenet. Have you looked at
make menuconfigat any point? There’s everything but the kitchen sink in there.Apples to oranges, and you can have a minimal kernel tailored to your needs.
They’re the main reasons, yes, but there are plenty others .
-
systemd is a godsend when you need service control while getting actual work done, at scale.
there are legitimate things to criticize but in general the rants are incompetent preaching to the uninformed.
I do not think systemd is bad, I (and personal preference here) much prefer it over the older style of init systems.
Quite frankly, one of the things that has always irked me about a portion of the Linux community is that as far as I know, a strength and selling point of Linux has always been the freedom of choice. And yet, people start wars over your choices. For example, I know at least on r/Linux if you were to make a post saying that you liked Snaps over Flatpaks you’d get torn to shreds over it. Wouldn’t matter what reasons you had either.
It is always something. Whether its about Arch vs other distros, Snaps vs Flatpak vs AppImage vs Traditional packaging, X11 vs Wayland, systemd vs Sys V/init.d, pulseaudio vs pipewire, etc.
I never understood why it mattered so much what someone ran on their own computer. Assuming they’re the only one using it, what is the big deal if they choose to run OpenRC, X11, Snaps, and Alsa?
And I get a bad feeling the next one is going to be immutable distros vs non-immutable distros, but I guess we’ll see.
Quite frankly, one of the things that has always irked me about a portion of the Linux community is that as far as I know, a strength and selling point of Linux has always been the freedom of choice. And yet, people start wars over your choices
the “war” about systemd was actually a discussion about the (continuing) ability to make choices, not that some people chose systemd over other options. One of the main points of the debate was that systemd was monopolizing the init process and turning gnu/linux into gnu/linux/systemd.
The assertion that people were just upset like little babies that some wanted to choose a different init is highly disingenuous.
And yet it’s the only argument you’ll hear. I don’t know what possesses some people to act like critcism of systemd makes you an entitled manchild, I suspect they might be imbeciles.
Snaps and Flatpaks, are essentially the same thing seen from a different angle, so anyone preferring one over the other, basically deserves whatever they get 😋
The rest… well, freedom of choice is one thing, but when discussing the pros and cons, there are likely people who got burned by the cons of any choice out there, and each choice has their fair share of cons, so it’s understandable that they’d sometimes get emotional.
Keep in mind that it all started 20 years ago with Pulseaudio. Pottering was not really a nice guy (on mailing lists ofc, I don’t know him personally) whose software I wanted on my machine.
Problem was never speed or even technical, problem was trust on original author and single-mindedness that they were promoting. Acting like it is the only way forward, so anyone believing in freedom part of free software was against it. Additionally, it was looking like tactics used by proprietary software companies to diminish competition.
It looked scary to some of us, and it still does, even worse is that other software started having it as hard dependency.
All of this looks like it was pushed from one place: Portering and RedHat.
While after 20 years I might have gotten a bit softer, you can imagine that 15 years ago some agresive and arogant guy who had quite a bad habbit of writing (IMHO) stupid opinions wanted to take over my init system… no, I will not let him, not for technical reasons but for principal.
I want solutions to come from community and nice people, even if they are inferior, I will not have pottering’s code on my machine so no systemd and no pulseaudio for me, thank you, and for me it is an important choice to have.
Those sound like perfectly valid reasons to me. Thanks for the illuminating look into it.
Keep in mind that it all started 20 years ago with Pulseaudio. Pottering was not really a nice guy (on mailing lists ofc, I don’t know him personally) whose software I wanted on my machine.
Poettering is like Torvalds: gruff when pressed, but not wrong.
PulseAudio is like systemd: dramatically better than what came before, and the subject of a great deal of criticism with no apparent basis in reality.
PulseAudio did expose a lot of ALSA driver bugs early on. That may be the reason for its bad rap. But it’s still quite undeserved.
Additionally, it was looking like tactics used by proprietary software companies to diminish competition.
This is a nonsensical argument. Systemd is FOSS. It can and will be forked if that becomes necessary.
Which, in light of recent changes at Red Hat, seems likely to happen soon…
Problem was never speed or even technical, problem was trust on original author and single-mindedness that they were promoting.
That’s because fragmentation among fundamental components like sound servers and process supervisors results in a compatibility nightmare. You really want to go back to the bad old days when video games had to support four different sound servers and the user had to select one with an environment variable? Good riddance to that.
I want solutions to come from community and nice people
Then you’d best pack your bags and move to something other than Linux, because Linus Torvalds is infamous for his scathing (albeit almost invariably correct) rants.
@argv_minus_one @monobot Pulse Audio is good for a desktop multi-program environment. Its optimized for context switching, however for MIDI applications it has too much latency and you need to use Jack.
@thanhdo @argv_minus_one @monobot What about Pipewire? Doesn’t that combine Pulseaudio und Jack capabilities?
PipeWire is a whole other audio manager that happens to be compatible with PulseAudio and JACK.
Poettering is like Torvalds
Lol, not even close. I am not talking about being harsh for writing stupid code. Nor I want to go 20 years back to proove it to some random person, do it yourself.
Systemd is FOSS. It can and will be forked if
Yeah, the same way chrome can be forked. No, software developed like that - in closed room just source being dropped on to community, what happened with PA and SD in the begging no one wants to touch. Gentoo had big problems just maintaing eudev and elogind to enable gnome and some other software to work.
Luckily, it is not important anymore, there is pipewire so I managed to skeep PA completely.
systemd isn’t bad at all. People simply don’t understand that it is not “just an init service”.
Systemd (the collection of components present in a typical distro) is like many other large frameworks:
It can do a lot, has some good design ideas at its core, and is certainly useful to a lot of people.
But the implementation is opinionated and invasive, so if your needs don’t happen to match what its author(s) envisioned, it can easily become more of a liability than a benefit. Making matters worse, it is buggy as hell.
I don’t think it’s helpful to think of the topic as “a rant”. Criticisms of systemd are diverse, and at least some of them are founded in practical experience. Being dismissive of them only stirs up resentment and division.
To be fair, we knew before it would be buggy and invasive. The actual surprise for me was failure of project governance, even with Debian. It was enough to consider me moving to *BSD, thogh they have their own share of issues.
It’s a massive question, and I think quite a lot of the argument comes from the fact that it depends what direction you’re answering it from.
As a user, do I like being able to just
systemctl enable --now whatever.service, and have a nice overview of ‘how’s my computer’ insystemctl status? Yes, that’s a big step up from symlinking run levels and other nonsense, much easier.As an administrator, do I like having services, mounts and timers all managed in one way? Yes, that is very nice - can do more with less, and have to spend less time hunting for where things are configured. Do I think that the configuration files for these are a fucking mess of ‘just keep adding new features in’ and the override system is lunacy? Also yes.
As a developer trying to do post-mortem debugging, who just wants all the logs in front of him for some server that’s gone wrong somehow, which I often have to request via an insane daisy-chain of emails and ‘Salesforce nonsense that our tech support use’ from our often fairly non-technical end users, on some server that I’ve no other access to? No, I do not find having logs spread between
/var/logand journalctl (and various CloudFormation logs in a web console) makes my life easier. I would be pleased if that got sorted out.tl:dr; mostly an improvement, some caveats.
As someone who recently started learning linux properly by setting up arch, systemd is nice. It does a lot of things that make life easier for me and it never gets in the way.
Edit: Please disregard, this should be a top level comment.
why did you ctrl c ctrl v your own comment?
Because it was intended to be a top level comment and I only noticed that I wasn’t commenting on top level after posting it.
Did the deletion of this one not get through to your instance yet?
oh, lol, it’s fine
Did the deletion of this one not get through to your instance yet?
probably
I didn’t know that logging question is related to SystemD, so thanks for telling it! As an non-top class desktop user the same thing frustrates especially because the solution is often simpler and not found from those logs.
What do you see wrong with the config override system? I find it an improvement over having to diff between new and current config files, then having to figure out which part of which to keep.
Just try to implement user session management on a non systemd distro…
Systemd is way better than others init system. I’m using Alpine Linux on my phone and I really wait for a Fedora/Arch like PMOS project (it’s on the way)
[]Just saying, not everyone needs session management…
sudo su
Why spawn additional process when you can get into shell directly with
sudo -s?Well, sudo itself is a purely optional component—you can run a system quite happily with just su .
What do you do with all the process you save with that trick ?
Because I already had my fingers closer to “su” than to “-s”… but more seriously, because I tend to use
sudo -E suon a remote terminal with a PS1 set to colorize the prompt based on whether I’m running root and the host if it’s remote, butsudo -E -sdoesn’t run the root’s.bashrcthat runs the updated colorization while at the same time exports too much of the user’s environment into the root shell.
I am fine with it and personally make heavy use of it. On my Arch install, I use systemd-boot, systemd-timesyncd, neworkd, resolved and unified kernel images with ukify.
Roast me you systemd haters.
Complains against systemd are not about boot time. It is about overengineering and vendor lock-in.
Please explain vendor lockin in this context to me. I’m not seeing it.
Is the current SystemD rant derived from years ago (while they’ve improved a lot)?
In my experience, the same arguments against systemd (not systemD) are still used. No matter how often they have been disproved or whether the problem has been fixed in the meantime. With many users I am sure that it is only about making the project systemd bad.
Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?
I would prefer it if there were no rants at all. No matter what the topic. Because that doesn’t help in any way. It would make more sense to invest the energy in the projects in question or in alternative projects to improve them.
I would prefer it if there were no rants at all. No matter what the topic.
I think it depends. A rant can be good if it is full of factual, demonstrated details about something that needs to be fixed. It is not so great if it just someone emotionally unloading about subjective preferences not going the way they want.
A lot of the people I see complaining about it are comparing to what was before it.
As someone who has only ever known systemd, I have no issues with it and, dare I say: I like it.
As someone who has been using Linux since the 90s and gone through many different unit systems, I like systemd way more than any of the past ones. It makes adding services dead simple, and is much smarter about handling dependencies and optimizing startup sequences.
The main complaints I’ve seen about it seem to be people that don’t understand that systemd init is a separate thing from all the other systemd stuff. If you don’t like all the other systemd things, you don’t need to install them at all.
As someone who used what came before systemd, I say you’re lucky you didn’t suffer what I suffered. Good riddance.
Speaking as someone who uses OpenRC on all my machines . . . no, systemd is not necessarily slow, and personally I don’t care about the speed of my init system anyway. Thing is, systemd also has nothing that makes it more useful to me than OpenRC, so I have no incentive to change. Plus, I dislike the philosophy behind it, the bloat, and the obnoxious behaviour the project showed when interacting with others in its early days. I’m a splitter, not a lumper, and systemd’s attempts to absorb All The Things strike me as rather . . . Windows-like.
So, in a technical sense I have no reason to believe that systemd is inferior to OpenRC + sysv, and it may be superior for some use cases which are not mine. I don’t spend a lot of time ranting about it, and I see no point in trying to convince people not to use it if it fits their needs. But I still won’t use it if I have another option.
I agree. SystemD is a great service daemon (or, sigh, unit daemon in the stupid parlance). I like unit file syntax and I like the ergonomics of
systemctl. It’s solid and I appreciate the feeling of consistency that systemd lends to the otherwise chaotic landscape of Linux distrobutions.It’s for this reason that I’m willing to forgive SystemD overstepping the boundaries of services somewhat. System init/mounting? Sure, that’s a blurry line after all. Logging? Okay – it does make sense to provide a single reliable solution if the alternative is dealing with dozens of different implementations. Network resolution & session management? Fine, I’ll begrudgingly accept that it’s convenient to be able to treat logins/networking as psuedo-services for the sake of dependencies.
If that’s as far as the scope crept, SystemD and I would be cool, but the so-called “component” list just keeps on going. SystemD has no business being a boot manager, nor a credential manager, nor a user manager, nor a container manager, nor an NTP client. I understand why they can’t deprecate most of this junk, but why can’t they just at least make this cruft optional to install?
Systemd (PID1) is not your boot manager, network deamon, resolver, user manager or ntp service.
Those are entirely independent deamons that happen to be developed under the systemd project umbrella but can be exchanged for equivalent components.
Tkey are gully optional.In many cases, the systemd project’s one is one of the best choices though, especially when used with other systemd-developed components.
In some cases, there is no other viable choice because the systemd-* is just better and nobody wants to deal with something worse.In all fairness, a lot of it is sort of optional if you’re compiling your own copy from source . . . which no one outside of Gentoo (/Funtoo/Pentoo/Sourcemage/LFS) ever does. I just had a look at the ebuild for systemd 253.5, and there are 37 USE flags, most of which translate directly to build options. Just figuring out which bits you want could take hours.
I’ve been using Slackware for more than a decade, and all this systemd talk has me feeling like I dodged a bullet.
We’d probably need to qualify this with “bad compared to what”. I can’t complain, as it does its job, and I’ve been able to tweak what I needed to. As I don’t tinker with it every week, I keep a sticky note rolled up on my desktop, or I quickly use ‘cheat systemd’ to remember some key examples.
I was getting really long start up time earlier this year (like 19 mins before the desktop was fully responding) and after trying everything else I tried ditching BTRFS and reverting my /home drive back to ext4. Turns out BTRFS start and checks was killing my boot times. Now, as fast as anything.
The following have been my saviours though in identifying boot times: journalctl -b -p err systemd-analyze blame --user systemd-analyze blame
