Hacker News Reader

Comment by dimgl | Hacker News Reader

What are some of the arguments against `systemd`? I've used it in several production systems and don't really have an opinion on it.

View on HN

I've grown to think its a very vocal minority that objects simply ideological reasons, then finds techincal reason to back that up

Even https://nosystemd.org/ mostly just lists bugs

After moving all my services from varius init systems to systemd, I'd never go back

I'm mostly a happy systemd user. Unit files are much easier to work with and more consistent than init scripts, the faster bootup (at least on my arch and Ubuntu systems, maybe you could make Gentoo even more minimal with initscripts), and the container/isolation features won me over.

That said, I can understand the objection to software that would previously support BSD or macOS now only providing systemd units or depending on other parts of the systemd project that in turn depend on the init making at a pain for portability across unices. Or software like gnome taking up huge amounts of time for the BSDs to support.

Unit files are great. SystemD should have stayed there. But then it handles networking(including configuring network interfaces), and time synchronization, and name resolution, and the kitchen sink.

systemd even had a type of container system (I think predating docker by a few years) but no one used it

https://wiki.archlinux.org/index.php/Systemd-nspawn

From an administrator's perspective it's the same problem with every declarative run control system: there is a layer of indirection between what's written in the configuration files and what the machine does (as opposed to an imperative system, where it's a bunch of shell commands that are literally the actions the machine takes).

With systemd in particular the indirection is notably (needlessly) opaque, with a big spaghetti mess of unit files symlinked in 18 different places, some of which have semantic meaning to the init system and some of which do not.

Branding perhaps. If 50 tools had been released, called "newInit", "newDns", "newNTP" etc, with each tool succeeding or failing (upstart) on it's own merits, that would be one thing.

There is a perception that systemd has taken over the entire system as a cancer - replacing things that have worked for decades just because it's cool.

One annoyance I get is this: I've just taken an Ubuntu 1604 server running apache and b0rked the config file.

  $ sudo systemctl restart apache2.service 
  Job for apache2.service failed because the control process exited with error code. See "systemctl status apache2.service" and "journalctl -xe" for details.
  $

That's crazy. "Something broke, now go look here or there for why". Compare under an old ubuntu 1404 machine I have lying around

  $ sudo service apache2 reload
  * Reloading web server apache2
  * The apache2 configtest failed. Not doing anything.
  Output of config test was:
  AH00526: Syntax error on line 1 of /etc/apache2/sites-enabled/sd.conf:
  Invalid command 'blah', perhaps misspelled or defined by a module not included in the server configuration
  Action 'configtest' failed.
  The Apache error log may have more information.

That is so much more helpful.

You run the first and it outputs the last few lines of log. Why not output that when I call restart in the first place?

Another one is taking over DNS from resolv.conf. Muscle memory from years of "cat /etc/resolv.conf" (with a tab somewhere in the middle) has been replaced with the ungainly "systemd-resolve --status".

Now all of this is great if you're running servers as cattle - if you have thousands of machines doing web-scale stuff you don't want to see what's happening on a single machine, your layers of automation abstract it all away, your system can cope with machines going down, you probably don't even have an ssh account.

If you are looking after individual machines though, systemd came in and turned everything upside down to presumably make things easier for cattle owners.

There is https://blog.darknedgy.net/technology/2020/05/02/0/ which puts systemd in its historical context, explains some of the criticism, and then goes into the technical details. It's a long post and the tone makes it difficult to continue reading at times, but I learnt a lot from reading it.

I for one think the team behind it and especially Poettering have incredibly bad taste in software, which bleeds into their designs, and possibly the worst attitudes and culture of any major OS initiative, making Linus look tame (hell, at least if he got bent out of shape he was usually right, and not just throwing a tantrum because he could get away with it). I don’t necessarily disagree with it’s goals, even, I just think the implementation’s not great and the team are, largely, self-righteous jerkasses. See links others have posted here, their attitude and demeanor’s pretty out-there.

I have used systemd successfully in production and have a positive opinion of it. I like that it is integrated, documented, and self consistent.

None of the negative ideological complaints against it resonate with me, as none of them seem to impact me (yet, anyways). My experience with past init systems is that they are cryptic and error prone.

Here's a good article that I saw on HN a few months ago: https://blog.darknedgy.net/technology/2020/05/02/0/index.htm...

Also: https://suckless.org/sucks/systemd/

Personally I avoided it for a while because of the hate, but haven't really had issues with it since using it.

Similar opinion here. I put it off for when I could learn it better, and so far it's been fine... sometimes nice too when it has a feature I want that's already built-in (depending on version level and all that).

Ditto. my personal experience with systemd has been "wow, it's easier than ever to write an init script that runs when it's needed".

Looking at the components that make up a modern UNIX system, it's definitely time to think "how can we make a new operating system, evolved from UNIX, but with a more coherent core running the majority of run time orchestration".

Thanks for the share from suckless.org. I'm interested to learn about init now :)

You may not realize you're inciting a flame war. If you google for this there's no shortage of arguments going back 10 years and continuing to this day

I didn't realize it was a touchy subject. That's my bad. I'll do some research on this.

oh no worries! I figured as much, hence my comment :-)

FWIW I really like systemd, but I agree the scope creep is real and isn't all positive.

"You can't discuss this topic because of a flame war" is ceding territory to the assholes. I'm willing to accept that when it comes to talking about political topics here, because this isn't a political forum, but I refuse to accept that we can't talk about technical topics here because some people refuse to keep a civil tongue.

One practical problem I've had is with journald. The log files are useless outside of the system they were generated on. They could have just used a simple text file and avoided major headaches.

Almost like with etcd, it started simple, but got expanded into a huge incomprehensible monster by the original developers. Politically and business-wise, systemd is a clear win for Lennaert and his clique, as well as the whole Redhat/IBM.

But I am sure that future historians will view the impact of systemd on computing as largely negative.

The systemd/RH relationship is complicated. Red Hat doesn't use most of systemd's features--they don't even ship systemd-networkd on RHEL8, preferring NetworkManager instead. On the flipside, I see more use of systemd's features on Arch or Debian.

I don't think you can frame systemd as some kind of RH trojan horse when so little of it makes it into RHEL/Fedora.

Greeks probably would not pull a Trojan horse into their own city either, despite making one for Troy.

So while Arch ships everything, and being Arch it doesn't really have a default, its recommended networking system isn't systemd-networkd but rather netctl, which is basically everything systemd-networkd should have been.

There is no recommended networkmanager.

`netctl` was explicitly written because systemd didn't have a network daemon. The past 3-4 years the community has in general recommended against using `netctl`.

It was never removed from the ISO because the releng maintainer didn't put that much thought into it, but I'm happy to tell you `netctl` was replaced with `iwd` on this month ISO release.

> But I am sure that future historians will view the impact of systemd on computing as largely negative.

I don't really think so. They probably will point out a lot problems with at some point somehow got fixed but it should be net-neutral or positive.

The thing is todays linux is running manny services and to do so nicely you want to have some form of service manager which does startup/shutdown/restart/circicute braking and helps with interconnect. Which is what systemd does and what mainly differentiates it from many previous systems which where mainly "just" start-up helpers. Through there are IMHO a large amount of problems with systemd the general approach is IMHO good, just the implementation isn't so much.

Sorry, no. Systemd doesn't add anything for service management that didn't previously exist elsewhere other than the unit file syntax for service definition. What it did is pull as many disparate aspects of "how do you run a thing" under its umbrella as it could, so it controls as much of the environment as possible and doesn't have to care about playing nice with anyone else. That's the general approach.

It's a logical fallacy to assume, because systemd was the thing that came along and resulted in the problems in sysv being fixed, that systemd's approach or implementation were necessary, desirable, or the best option available.

It violates the old school UNIX Philosophy of (1) simple standalone tools (2) text as the universal interface.

(1) systemd is a monolith that aspires to do almost everything from booting to networking to sound. It's in many ways a Kubernetes sans distributed systems.

(2) systemd uses binary logs, abandoning "text is the universal interface"

systemd is also a giant single point of failure.

Personally I don't see the big deal. The actual reason people hate systemd is that it's the type of design a software company like Microsoft would come up with rather than one that a bunch of gritty basement hackers would create. They have found refuge in OSes like Gentoo and OpenBSD, so systemd served as a kind of explusion of this type of programmer/user from the Linux ecosystem.

i went trying to learn how to make my linux box do something at startup.

as somebody learning how to use my linux, systemd clouded the discovery process of learning how to linux in the intended way.

i ended up using systemd, but now that's the thing i'm familiar with if i want to add some service to my computer... so it has infected me with some non-linux-y knowledge that won't go away soon.

Also compare it to doing things the Windows way: Something to run on startup? Put it in the "Startup" (magic) folder. Want something to do the things a service does, where it gets auto-restarted and auto-run and even logs success and failure? Like three clicks can run arbitrary anything using the scheduled task GUI and things get auto-logged in the Windows Event Log

i guess if i wanted windows, i could use windows... right?

edit for tone:

sry, that sounded saltier than i wanted. i actually went to linux because i was convinced that was the better way to do things, and i wanted to do things the better way.

i trust neckbeards over most others.

https://nosystemd.org/

I feel like this page actually comes off as a pretty good recommendation for systemd. Like it's a piece of software with normal bugs and the usual crop of hard decisions.

Reply on news.ycombinator.com