Is Systemd that bad afterall?

Nuuskis@sopuli.xyz to Linux@lemmy.ml – 120 points –

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:

  1. Is the current SystemD rant derived from years ago (while they've improved a lot)?
  2. Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?
181

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:

  1. 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)

  2. 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.

One of my biggest problems with critics of systemd is that a lot of the same people who make that second point also argue against wayland adoption when xorg does the exact same thing as systemd. It makes me feel like they're just grumpy stubborn old Linux nerds from the 90s who just hate anything that's not what they learned Linux with.

Which is sad, because honestly I think it's kind of not great that an unnecessarily massive project has gained such an overwhelming share of users when the vast majority of those users don't need or use most of what it does. Yeah, the init systems from before systemd sucked, but modern alternatives like runit or openrc work really well. Unfortunately they get poorly supported because everyone just assumes you have systemd. I don't like the lack of diversity. I think it's a problem that any init system "won".

Unfortunately they get poorly supported because everyone just assumes you have systemd.

No, they get poorly supported because they were a pain to support even before systemd ever showed up. I for one was extremely tired of writing the same shit over and over again in every init script and then going through the tedious process of porting the script to every platform for minor idiosyncrasies of the various distros (start-stop-daemon available or not was one I remember, the general bash/GNU vs. BSD stuff you get with any script was another) from 10 year old RHEL to modern ones.

Maybe systemd gets grouped with wayland and xorg with other init systems simply because of usability?

I mean, I got used to the thought that what I prefer is less usable, because some pretentious UX designers say so, and we Unix nerds use inconvenient things because we are all perverts.

But when I read about industrial design and ergonomics, it seems that my preferences are consistent with what I read, and all those UX designers and managers should just be fired for incompetence and malice.

Back to wayland/xorg and runit/systemd (for example), same reason FreeBSD may seem easier to set up and use than an "advanced" Linux distribution - there's less confusion.

Xorg, or X11, "used to" do the "minimum necessary" for a remote display system... in the 80s. Graphics tech has changed A LOT in the last 40 years, with most of the stuff getting offloaded to GPUs, so the whole X11 protocol became more and more bloated as it kept getting new and optional features without dropping backwards compatibility.

The point against Wayland, was dropping support for remote displays, while kind of having an existential crysis for several years during which it didn't know what it wanted to become. Hopefully that's clear now.

OpenRC and runit are indeed working alternatives, but OpenRC is kind of a hack over init.rd, while runit relies a bit too much on storing all its status in the filesystem. Systemd has a cleaner approach and a more flexible service configuration.

I like it too. Very easy to work with and set up services as needed.

"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 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.... The service format makes more sense when you're seeing it as "run this script to control this service". The systemctl format 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!)

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 menuconfig at 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.

systemd isn't bad at all. People simply don't understand that it is not "just an init service".

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.

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.

@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.

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' in systemctl 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/log and 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

Alright, I thought I was quick enough but deletion seems to work differently in the federation. I restored the comment and added an edit, that should avoid confusion once everything is synced properly.

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.

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.

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.

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)

[pi@raspberry]# sudo su

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 .

Because I already had my fingers closer to "su" than to "-s"... but more seriously, because I tend to use sudo -E su on 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, but sudo -E -s doesn't run the root's .bashrc that runs the updated colorization while at the same time exports too much of the user's environment into the root shell.

What do you do with all the process you save with that trick ?

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.

Ok, so I have a very unique background in systemd. I worked at Red Hat supporting it basically as the primary support and I've worked with the developers of systemd at Red Hat directly. I no longer work there.

So first off, it's "systemd" all lower case. I don't care, but for some reason Lennart Pottering (creator) does.

systemd was a MASSIVE change. And Red Hat did a TERRIBLE job relaying it. To the point where I'm still trying to get my company to understand that it can NOT be treated like the old init systems. You can NOT just drop an init script in place and walk away and hope it works. Because a LOT of times it doesn't. Due to forks, switch users, etc.

systemd is NOT an init system. RHEL 5 and older had sysvinit as it's init systemd. RHEL 6 had UpStart as it's init system and looked exactly like sysvinit that no one even noticed. systemd again is NOT an init system. Init system is 1 part of systemd. systemd does a lot of cool things. It bundles applications together, it manages those applications and can restart them or kill children, it can do resource constraints, it separates out users from the system, and lots more.

Because it is not an init system there is a LOT LOT LOT of bad recommendations out on the internet where someone has X problem and person suggests Y and IT WORKS! ... except it doesn't REALLY work as far as systemd is concerned and you'll hit other issues or your application takes longer to start or stop and people just blame systemd.

It is systemd's fault that it has done an ATROCIOUS job of helping people adapt. It's a great example of RTFM. systemd's man pages are INCREDIBLE and extensive, but when you drop so much knowledge it becomes more difficult to find what you want/need. systemd.index and systemd.directives are your best bet.

So systemd does a lot of amazing things that sysvinit never attempted to do. It's never attempted to explain anything it expects everyone just learn magically. it's INCREDIBLY complex, but once you understand it's basics you can more easily get an application running, but as soon as there's a problem it'll just break your brain.

To give you an example, sshd's old init script is like 250 lines of bash. systemd's unit file comparative is like 12. Because systemd handles a LOT of what you manually had to handle before. BUT to get to that 12 you literally have to learn EVERYTHING new.

There is no "is it good or bad" here really imo. It's a completely different fundamental design. Red Hat made it for themselves. Other distros picked it up. It can be argued that lots of folks followed Debian and Debian had a few Red Hat board members that were pushing it. Whether they pushed it of their own accord or because they were with Red Hat I don't have a clue.

What I can say is at my current company they're suffering from a LOT of systemd issues and they don't even realize it. I've been working with Red Hat to try to get Insights to alert people to the failures and we're making progress.

To see if you have issues just to start run the two following commands:

# systemctl list-units --failed
# systemd-cgls

If you have any units that are failed, investigate those. If you don't need them, disable them. As for the systemd-cgls this shows HOW systemd is grouping things. ANY application that runs as a service (or daemon or application or runs in the background or however you wanna say it) should be under system.slice. ONLY humans logging into the system (meat bags NOT applications switching to users) should be in user.slice. A LOT of times what happens is an old init script is dropped in place, they start it, it has a switch user and systemd assumes it's a user and puts it into user.slice. systemd does NOT treat anything in user.slice the same as in system.slice and this WILL eventually cause problems.

So again, is it good or bad? Eh. It does a lot of cool things, but they did a MASSIVE disservice to ALL of us by just expecting to relearn absolutely EVERYTHING.

sshd's init script under OpenRC is 87 lines, of which around half are blanks, comments, closing braces, and other boilerplate. Granted, that still makes the real code maybe three times the size of your systemd unit file, but the difference isn't as impressive as you're making out.

95% of people shouldn't need to poke around in their init scripts or unit files anyway. If you actually need to do that, your use case is already somewhat unusual.

As an end user, unless you're running a server, then no you shouldn't have to mess with any of it.

If you're running a server or a sysadmin you absolutely 100% should be paying attention. Almost every single vendor I've seen selling their applications only have initscripts. Which then cause issues. I've gone to the vendors and told them and they've said go to Red Hat. Well Red Hat doesn't support that vendor's init scripts.

Not naming an application, but it was from a BIG BLUE company and they said their only instructions are to call their script from the user. But it won't remain running if you do that because systemd will close out the slice when the user logs out. SO it's obvious they haven't tried what they're suggesting.

And I'm not attempting to state that systemd is impressive in any way. systemd basically took what had been building over 40 years of init scripting and threw it out the window and said our way is better. I don't think it is. I'm just saying, with a directive based unit file it'll be simpler to parse than a bash script.

Yeah, the landscape changes if you're a professional sysadmin running multiple servers with uptime requirements, and possibly proprietary software or unusual hardware. I contend that that is, in and of itself, not the most common use case. 😉

Fedora uses dracut as opposed to initramfs, so that's also a major difference.

I've been using Slackware for more than a decade, and all this systemd talk has me feeling like I dodged a bullet.

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.

The Systemd init system and its consequences have been a disaster for the human race. It has greatly increased the life-expectancy of those of us who live in “just werks” distros, but it has destabilized GNU/Linux society, has made life unfulfilling, has subjected users to indignities, has led to widespread psychological suffering (in the BSD world to physical suffering as well) and has inflicted severe damage on the Unix world. The continued development of Systemd will worsen the situation. It will certainly subject human beings to greater indignities and inflict greater damage on the Unix world, it will probably lead to greater social disruption and psychological suffering, and it may lead to increased physical suffering even in “just werks” distros.

The Systemd system may survive or it may break down. If it survives, it MAY eventually achieve a low level of physical and psychological suffering, but only after passing through a long and very painful period of adjustment and only at the cost of permanently reducing users and many other Unix processes to engineered products and mere cogs in the Systemd machine. Furthermore, if the system survives, the consequences will be inevitable: There is no way of reforming or modifying PID 1 so as to prevent it from depriving users of dignity and autonomy.

If the system breaks down the consequences will still be very painful. But the bigger the system grows the more disastrous the results of its breakdown will be, so if it is to break down it had best break down sooner rather than later.

We therefore advocate a revolution against the Systemd system. This revolution may or may not make use of violence; it may be sudden or it may be a relatively gradual process spanning a few decades. We can’t predict any of that. But we do outline in a very general way the measures that those who hate the Systemd system should take in order to prepare the way for a revolution against that form of society. This is not to be a POLITICAL revolution. Its object will be to overthrow not distros but the init-system basis of the present GNU/Linux ecosystem.

Complete this sentence: As an AI language model ...

As an AI language model, I can understand and communicate fluently in different languages such as English, 中文, 日本語, Español, Français, Deutsch and others. Here are some examples of how I can complete the sentence:

  • As an AI language model, I can translate text or speech from one language to another.
  • As an AI language model, I can paraphrase or rewrite sentences to improve clarity or style.
  • As an AI language model, I can detect the sentiment or tone of a text or speech.
  • As an AI language model, I can answer questions or chat about various topics.
  • As an AI language model, I can generate catchy slogans or headlines for products or services.

Which one do you find the most useful? 😊

If we are talking about desktops and servers then yes and yes.

However SystemD in an embedded system with tight process serialization needs, it's hell on earth.

Yes and yes.

Personally I always found systemd amazing, it brought logic and order in the init world.

Finally some consistent API and predictable behavior.

Exactly. People are pretty averse to consolidating on something new, but let's be super honest here. SystemD is pure FOSS and not going away anytime soon. It's design is reasonable and brings a good deal of useful features. Also, main distros being a little more similar because they all support SystemD's API/config is an absolute win for me!

linux is also about choice, so it doesn't matter if something is bad for you. you can use a different alternative or even make/fork one.

This is the first top-level comment that hints at the main criticism against systemd. systemd is increasingly difficult to replace as time goes on. I like and use systemd because it has a fast boot, but I wish the project was developed in a more modular way that had choice built-in. It is instead developed as the way that everyone should systemd instead of alternatives. This philosophy gets in the way of distributions that want to provide alternatives (Devuan, Gentoo, Parabola, etc.). Some of the sysadmins I work with closely use Devuan and follow development. I hear the patch set around bypassing systemd grows in size and complexity each year which is worrisome for choice.

Well, no, and that's the whole problem; Systemd removed choice, and it was designed to do so. That is why there is so much anger. It is bad software design, by design. It flies in the face of the core linux principles, all in the name of homogenising the linux ecosystem, and you know exactly which big corporations benefit from that.

The simple fact is: today, if I want to run a mainstream distro without Systemd, I cannot. Its cancerous tentacles run so deep that decoupling it from a mainstream distro, and keeping it decoupled, is a full time job.

Instead I have no choice but to run a smaller, less featured, less secure and less funded alternative.

Full credit to Devuan, MxLinux, Artix, and the other united underdogs.

Fuck you Redhat/IBM and your proxy evil-doer Lennart.

Lets be perfectly honest. The reason systemd is so popular is because the init script based predecessors were so bad in so many ways. Not only did you have to reimplement the same things over and over in every script, the behaviour of your script also depended on environment variables in your environment while you started a service and other things that leaked into the script.

Would an init system have to do as much as systemd does to fix those issues? No. Are the existing alternatives really, really bad? Yes.

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.

What DE/WM you chose with your Arch? Wayland?

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.

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

It's not THAT bad. It was THAT BAD remembering who invented and pushed it. You know, all these psh-sh-sh-sh-audio memes. People just do not want to:

  1. Use software written by developer who didn't manage previous project to work properly.
  2. Change anything if it just works (c)(r)(tm).

Currently systemd does its job well and right, despite on fact that systemd not so modular as you would expect. Event hardcore systemd haters now using it and happy. Including me :)

I guess I'm in the camp if it doing too much. I prefer each program has its own script to run in a more isolated manner from anything else the system does so if one program locks up everything else on the system runs independent from the other software that has stopped responding to system calls.

I partially agree. But on the other hand I like the convenience.

Example: I need to enable ntp client on a machine? Just enable and start the service and done!

I enjoy the seamless experience it offers. I doubt Linux in general could be noticeable faster with better optimized SystemD or with perfect init for speed.

I think it is one of those situations where everyone complains about what they use.

The reality is that system startup is insanely complicated due to the nature of software dependencies, and there will never be a perfect solution across multiple distros.

Lot's of things in computing should be simplified. Especially bios firmware / boot process. It has become overly complicated mess offering zero value for anybody. In 10 years the bios chip size has increased from 8 mbit to 256 mbit and no features added. Only TPM 2.0 has been added, but it is another chip than bios.

Haven't you heard? The UEFI bios can have binaries included by the board manufacturer that Windows will ask for and automatically run on startup... for example to download a GigaByte control center installer to fill your recent install with crapware... that would then proceed to download a self-update from a http (no-s) URL. And the binaries will work even if they're signed with revoked certificates and have been injected by any device with DMA access!

That's... like... super cool, isn't it? If only we could have that on Linux... /s

Also, the modern bioses have pretty graphics and mouse support... /s/s

I noticed this driver crapware by updating the mobo bios I bought used. Luckily MSI has a rollback tool lol.

My i5-2500K had a nice GUI bios with 16 mbit bios chip. Including UEFI and Secureboot and other modern features.

No. The people with a raging hate boner for systemd are just a vocal minority in lots of online Linux spaces.

Most people either don't care or actively prefer it. Personally, I much prefer unit files to hacking away at init scripts or whatever the fuck Upstart was.

No, it's not bad.

tbh, I've always like Apple's launchd.

Getting a "control center" for your init, with user groups, modularity, memory limits and queryable status/control is great. (Sometime people forget how painful init scripts can be...)

The only problem I see is the tendency to cram everything into systemd.

I absolutely agree with you, but not quite on the las point. SystemD is modular, right? I can still pick and choose something else for tasks that SystemD handles. Also, it might be a good idea anyways to centralize some common tools for distros and devote developer ressources somewhere more specific and necessary.

It'll always be an open field of software stacks to choose from, but having one big, featureful and solid base stack for most usecases seems like a win to me. It's all completely FOSS anyway, it's not like we are risking a vendor lock-in here.

It often feels like people only complain about things because they are not used to them

As service manager systemd nice, but look all services:

systemd + systemd/journal + systemd/Timers
systemd-boot
systemd-creds
systemd-cryptenroll
systemd-firstboot
systemd-home
systemd-logind
systemd-networkd
systemd-nspawn
systemd-resolved
systemd-stub
systemd-sysusers
systemd-timesyncd

That's look as overkill. I use only systemd, journald, systemd-boot, systemd-networkd, systemd-resolved and systemd-timesyncd, but that a lot systemd. Feel like system make monolith.

systemd-nspawn for example. Systems manager for containers. Seriously. Why than exists? I don't understand. Really, someone use that daemon?

I think that's a bad argument. If you go out of your way to install and configure all of these, then yes, they exist and you can do that - but that doesn't automatically mean they're bad.

But in most operating systems they're not installed, not configured, and you'll never have to deal with any of that.

I actually use systemd-boot because it's very easy to install and configure and systemd-resolved, but for a lot of those I haven't even heard about.

And furthermore even if more of them (I think it's highly unlikely that any OS would use all of those services by default) were preinstalled, they'd only be an issue if they'd cause trouble. If your system is running systemd-whatever and it works well then what's the issue? The name itself?

As I wrote below, the problem is that this does not comply with the principle of K.I.S.S. One application should solve one task and can be replaced. Even now it is quite difficult to remove systemd-logind, for example. Because, although these are different services, they have long merged into a huge tangle.

I actually use systemd-boot because it’s very easy to install and configure and systemd-resolved, but for a lot of those I haven’t even heard about.

you can use EFISTUB If you don't have dual boot. This literally load kernel from UEFI. I don't know more simple way. https://wiki.archlinux.org/title/EFISTUB

does not comply with the principle of K.I.S.S. One application should solve one task and can be replaced

That's not KISS, but the UNIX principle. And even that part is wrong, as in traditional UNIXes applications were certainly not replaceable.

can't you replace UNIX applications in user space? Why, besides the fact that some simply have nothing to replace?

How you would replace those in non-SystemD setup? Asking for learning purposes.

or maybe I didn't understand the question. If you about that change daemons to non systemd, then:

systemd-boot -> grub, lilo, efistub

systemd-networkd -> some system scripts (different for different distributions), netplan, NetworkManager

systemd-resolved -> dnsmasq, bind, set directly on 8.8.8.8

systemd-timesyncd -> chrony, ntp

journal -> rsyslog

systemd -> init.V, openRC

In fact, this is a difficult question.

In Linux, it is usually customary to use the K.I.S.S. methodology, In any case, it was once customary to use it. This in some way meant that there were a huge number of applications performing exactly one task. For example, chron only started timers, ntpd only adjusted the time, grub only loaded the system and nothing else. It also allowed you to change the components at your discretion. With systemd this principle was somewhat lost, since one service with a huge number of its own daemons absorbs more and more functions. This is what causes concern. In some sense, if systemd at some point becomes even more monolithic, it will no longer be possible to change only part of its functionality. For example, I'm not sure if it's possible to disable journald and leave only rsyslog.

On the other hand, the now-forgotten init.V fully adhered to the principle of K.I.S.S. since he was literally the initiator of a set of scripts that could contain anything. If you want, change the user at startup via exec, if you want via su. Isolate the application with any available program. It was as flexible as possible, but on the other hand, the entry threshold was quite high. The complexity of writing scripts for init.V was much higher than systemd.

Therefore, there is no single answer. On the one hand, init.V have maximum modularity, on the other hand, systemd have ease of use.

Sys V init systems were really not K.I.S.S. since it was anything but simple to write an init script in a way that worked without e.g. having the environment of the calling user leak into your script and influence its behaviour or breaking things when called by the wrong user,... Not to mention all the re-implementations of the same functionality and the difficulty of writing an init script that worked on more than one exact OS, distro and version.

Right. But on something more complicated than initializing the usual daemon, systemd has all the same problems. For example, if you have a java application and you want to dynamically manage java parameters and application parameters, the script will look like a pain. something like bash -c 'java ...' or you will have to call a separate script in the initiator. And then to turn off the shell and switch to the application itself, there will be a whole adventure with pid generation.

But sure systemd really more easy then system V.

if you have a java application and you want to dynamically manage java parameters and application parameters

If you mean you want to auto-detect appropriate values that is no more complicated than the init script was before. You just call that wrapper script.

If you mean you want to turn those on and off as part of your local configuration that is actually quite easy with drop-ins in systemd, much easier than modifying the init script and then having issues with the package overwriting your script with a new copy.

I don't deny that systemd is easier than SysV. I say that on complex configurations it is not slightly simpler. Moreover, what I could do just in the sysV script, I now have to divide by tmpfiles.d and systemd. And sometimes even include processing both there and there, because depending on the version systemd has different behavior with parameters LogsDirectory= and RuntimeDirectory=. As a result, the dependence on the system has not completely disappeared for the package maintainer. Although of course there are a little less problems with systemd.

On other side as a user, I don't really like to guess exactly how a folder was created in /run, via tmpfiles or via systemd.

UPD: On SysV I have one complex, heavy script. Now I have the systemd service, the tmpfiles configuration, the /etc/conf parameters file.d and there is still a shell script to run. But if user wants reconfig something he need look 4 files instead one.

It's never been customary to adhere to KISS in Linux. This whole explanation reads like it came out of a game of Chinese whispers.

AFAIK, nspawn is mostly a debugging tool for working with the init system without having to actually boot a live system/VM. At least that's all I've ever used it for.

It also a use case. =)

The documentation for systemd-nspawn itself says:

systemd-nspawn — Spawn a command or OS in a light-weight container

The developers themselves position the daemon as a simple alternative to LXD containers.

Feel like system make monolith.

you do know what the linux kernel is, right?
Spoiler: It's a monolithic kernel

In the end your distro packager decided to not split systemd into different packages, I believe only Gentoo does actually guide you to this
so you actually barking on the wrong tree

you do know what the linux kernel is, right?

I know that the core is monolithic.

In the end your distro packager decided to not split systemd into different packages

I installed these services myself, not all of them, of course, but those that I listed at the end. I know about the rest simply because I prefer to read the documentation for the services I work with. I'm not particularly happy with the systemd system as a whole. however, since there is no better alternative, the choice is small.

I'm honestly a big fan. Systemd-init has tons of options like run targets, sandbox options, users you want things to run as, etc. System-oomd has tons of qol stuff for desktop users to help with stutter and responsiveness. I am also kind of excited for UKI that systemd-boot is set to support.

For someone coming from NeXTStep (BSD based), having worked with SCO, various BSD and mostly Linux for the last 20 years, the worst thing about systemd is documentation that's easily accessible/readable for people used to a traditional init system.

"How do I get it to do special use case X" was a basically unanswerable question when it got dragged into the mainstream (for reasons I can very well understand - the reasons for the dragging, that is, the bad docs, not so much).

Maybe that's improved in the mean time - I wouldn't know, I had to figure it out back then and now I know its lingo when searching and such.

I go crazy over boot times, systems is faster on every machine I’ve tried it on. The biggest difference I’ve seen is replacing grub, both systems-boot and car-boot seem to shave off a decent amount.

systemd-boot vs. GRUB should make no appreciable difference other than default timeouts and those are configurable.

As a guy that's been installing Linux since you had to compile network drivers and adjust the init scripts to use them; SystemD rocks.

Not against systemd (although it’s bad and needs replacing), just against pottering.

I make plymouth do the verbose mode because it's cool and hacker-y. Also I like when it says "failed" and I know what failed. For a few weeks I kept having to manually start firewalld and I never would have known otherwise, update seems to have fixed that though.

Tbf, I really only have experience with fedora and thus systemd, so, I like it but I "don't know what I'm missing" in a sense.

  1. Is the current SystemD rant derived from years ago (while they’ve improved a lot)?

No it's almost always been derived from people's behinds.

  1. Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?

Yes.

Systemd is spectacular in many ways. Every modern OS has a process management system that can handle dependencies, schedule, manage restarts via policy and a lot more. Systemd is pretty sophisticated on that front. I've been able to get it to manage countless services in many environments with great success and few lines of code.

Boot times aren't really an issue and not really relevant to good vs bad. You should be able to rice each one for speed on your particular use case if you really want to.

Be wary of anything you get from RedHat. I use their stuff sometimes but ensure I can happily live without gnome, systemd, pipewire, wayland or whatever else they are generously gifting to us freeloaders.

SystemD is blamed for long boot times

That is and always was nonsense. Systemd shortens boot times by starting things in parallel. That's one of its key features.

There are some things to note about that:

Systemd only starts services in parallel when it isn't told otherwise by Before and/or After settings in the service files. This makes it pretty easy to make systemd slow by misconfiguring it. You can use the systemd-analyze program to see which services held up your boot.

Systemd has a very long default timeout (90 seconds) for starting or stopping a service. It's appropriate for the big, lumbering servers that systemd was probably designed for, but it might be wise to shorten the timeout on desktops, where a service taking more than 5 seconds to start is almost certainly broken. It's a setting in /etc/systemd/system.conf.

Is the current SystemD rant derived from years ago (while they’ve improved a lot)?

I'm an early adopter of systemd. I installed it on my Debian desktops pretty much as soon as it was available in Debian, and I later started moving servers to it as well. I had long been jealous of Windows NT's service manager, and systemd is exactly what I had hoped would come to Linux one day.

Yes, the rant you're talking about is old, and yes, systemd is better now than it was then, but not in the sense of what the rant was complaining about. The rant was already patent nonsense when it was written, which has given me a very dim view of the anti-systemd crowd.

Besides systemd proper, they also spent a lot of time ranting about the journal system, which redirects syslog entries into a set of binary log files. They complained that this would make logs impossible to read in emergencies. This isn't even close to being true—any emergency bootable Linux image worth its salt has a copy of journalctl on it—and the binary nature of systemd's logs has caused me serious problems on exactly zero occasions.

Yes. Yes it is. systemd isn't bad for boot times, but more for tying so many goddamn things to init, PID1, creating just about the best attack point one could ever ask for. Wayland not being ready can be solved by not using it for the time being. Just use X. Also, it's still called plymouth.

Why do people keep insisting on capitalizing it wrong? It's systemd, all lowercase. Never has it been Systemd, and never has it been SystemD.

Proper nouns should never start with a lowercase letter

proper nouns like sed, awk and grep?

Lowercase when referring to the command, uppercase when referring to it as a project or a piece of software as a whole. "grep" is a command with certain behavior; Grep (or GREP) is a tool on Linux.

How does that sound?

There's some reasonable overlap where you might mean one or the other, but to maintain that there's no reason to make it uppercase?

Exhibit A: https://www.gnu.org/software/grep/

  1. systemd hasn't become a better project built by better, smarter people to deliver a better set of features. It's still hot garbage.
  2. it's okay to continue pointing out it's hot garbage, in the hopes we can go forward or back or just get on something better/else (same thing).

The problem of systemd is that it hasn't been just a replacement of init as they initially claimed, and now deny they ever did. Things like Mono, Gnome and systemd are bad for the ecosystem long term.

An init done by constructive people wouldn't be a problem at all.

The problem of systemd is that it hasn’t been just a replacement of init as they initially claimed

Apart from the PID 1 part of systemd, almost all tools are optional.

Although I have a positive opinion about the systemd project, I used netctl instead of systemd-networkd for a long time without any problems. And even today I don't use systemd-resolved because I use a combination of unbound and Pi-Hole in my private LAN. And so on.

So you can't say that the systemd project has replaced various solutions in such a way that you don't have a choice anymore.