Hacker News Reader

Comment by georgyo | Hacker News Reader

systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd.

Upstart was almost good, but its really frustrating to use. OpenRC is decent, but confusing.

systemd solved problems, not only that it solved them well.

The scope creep of systemd is something that is a bit alarming, however even with the creep it's doing a good job. The tools that it is building work fairly well, and its a relatively new project.

View on HN

The only thing systemd solves, and I will say this is a big problem, is full process management. It also unifies startup scripts which does make it easier to support multiple distributions with a simpler packaging process. I'll give you that too.

The scope creep is really bad. It's not just bad, it's terrible. I don't want a program that's an init, and replaces xinitd and replaces my logging system and replaces cron. That's all totally beyond unnecessary.

Even with full process management, I'd hardly say it is the best. I have had cases where I stopped a service on a systemd box and it did leave child processes running. It's command line tools are terrible.

In fact it's this creep that keeps people from even being able to make drop in replacements. uselessd was a fork that kept up for a bit, but lost maintainership. With systemd being RedHat funded for full time development, it's very difficult for independent programmers to put in the time to make anything that can get adopted in the way it is.

I know not everybody has the same needs, but at least for me, systemd did not solve any problem I had. In fact, I found that it's main selling point, "better" service management, got much worse.

Before, I could simply do "sudo service xxx start". Now, with systemctl, everything is much more cumbersome. Just run "systemctl list-units". Ho boy, you get a huge list of... things. Not just what used to be called services or daemons, but units belonging to mount points, /dev entries, and who knows what.

Granted, it is probably easier to create service scripts for developers than with init.rc or upstart (although I never had a problem the few times I had to muck with them). But as a simple consumer, I do not feel systemd solves any problem I had. It just made things some things that worked fine before slightly more confusing, and there are some regressions every now and then while other programs are getting ported to systemd.

The one thing that is painfully obvious about the situation with init systems is that people have strong opinions about their preferences. And that makes the systemd situation even more terrible, since it's a choice unwillingly foisted upon a huge number of people. This situation really deserves some choices. For me, that is the number one reason I do not like systemd, even if it's solved some problems.

I agree with your reason, however for me they get outweighed by other factors. If I am a maintainer of a popular distribution, I want my distro to have the best init system, and I want that init system to have the largest user base.

EL6 and its derivatives was upstart, debian and its derivatives was upstart. The vast majority of linux systems were upstart for a long period of time. Other systems did not switch to upstart, because it introduced headache.

Switching init systems requires quite a bit of work. The fact that they all switched to systemd shows that beyond political pressure, they needed a better system.

The choice that was put before the Debian TC was literally "Should we use systemd instead of sysvinit" and did not consider any of the many other init systems. In fact, a motion was put forward to the Debian TC to consider other init systems, and guess what? Pro-systemd TC members pointed to the original motion ("Should we use systemd instead of sysvinit") as the reason not to consider other init systems. That is pretty much as political as it gets.

For the record, this post is completely false, as even a cursory glance at the relevant Debian bug report will prove: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672...

  We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be

  D    systemd 
  U    upstart
  O    openrc
  V    sysvinit (no change)
  F    requires further discussion

  [...]

  Therefore, the resolution reads:

  We exercise our power to decide in cases of overlapping jurisdiction
  (6.1.2) by asserting that the default init system for Linux
  architectures in jessie should be systemd.

I don't think the distro maintainers had that much say, since the most popular Linux desktop software began to depend on it. It started with GNOME, and now KDE is on its way. This basically forces their hand--if they want to provide a good out-of-the-box experience, they either have to switch to systemd, or continuously fight upstream's patches.

That's not my recollection. Upstart was an Ubuntu project, Debian never adopted it. Red Hat picked up upstart, then Poettering managed to convince them that they'd be better off with one they controlled. Somehow that filtered back through to Debian, and they jumped straight to systemd from sysvinit.

At no point was it necessary for systemd to actually be better than upstart at being an init system. It just had to be bigger by the time it got to Debian.

There are exactly two compelling (for me) arguments against systemd, and one that seems to result from it's current focus:

* Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.)

* Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it.

* Servers - systemd seems to be focused on a desktop lifecycle, where users interactively log in, have settings and log out. It is less clear how secure or well this inter-operates with services running as 'users' for privilege separation. I think this may have recently gotten better.

All of these are false.

It stores everything in binary logs, however your old system didn't store it at all. You had a daemon (syslog, rsyslog, etc) that wrote them as plain text. If you start those daemons, you at exactly the same spot as before. Just with an additional copy in a binary log. Which btw, journalctl can do some magical things, and you should take some time to play with it.

systemd is not monolithic, or at the very least its a distributed monolith. The vast majority of services happen in their own userspace process.

Systemd excels with servers, since it standardizes how their execution gets defined. It takes only an added line to spawn them in their own namespaces, set cgroup restrictions, prevent network access, etc. Before hand, doing these things was very hard, so no one did them.

If you had a basic syslog setup, it stored as text files. However, a more interesting syslog setup would take those entries and send them to a remote database, filter them to match certain contents, run scripts based on those matches, etc. Systemd only seems magical because most distros don't use even a sliver of the abilities that modern syslogs provide.

Systemd is a Jenga tower. Yes, there are lots of little pieces, and yes, removing a few won't hurt anything, but it's still fragile, and rather inconsistent. "Parts" like the journal, are a separate executable, but are not managed like other services. It uses a poorly documented ipc interface to talk to the various parts, and the configuration files are a nasty tangle of symlinks and control files stretching across the filesystem. It's just not a very well engineered piece of software.

Yes, these are also reasons I dislike systemd. Also, one of the original selling points of systemd was "It will reduce boot times significantly!" ... And then it ends up that systemd is actually slower to boot than any of the other ones out there.

it can be with the process timeout weirdness, where init used to be 'fire and forget' so if something didn't respond it would carry on systemd actually depends on the output so will sleep for 180seconds or so.

But honestly, even an extra 30s booting a server is nothing, I don't give a shit about boot times on my servers.. I care about what order my services are started in- my servers should be 100% reproducable otherwise you could have bugs that never get found except in 1% of cases.

And since it's turtles all the way down 1% of one system can be a lot of problems in a 2,000,000 server architecture.

So "Fast boot" in the way systemd achieves it is not beneficial for me.

> Also, one of the original selling points of systemd was "It will reduce boot times significantly!"

It was not.

http://0pointer.de/blog/projects/the-biggest-myths.html

Myth: systemd is about speed.

http://0pointer.de/blog/projects/systemd.html The original blog post introducing systemd on 30-APR-2010.

The first points that it details regarding the thesis of systemd is that it is a good init system, and a good init system is fast, and that SysV init is not fast.

The first time it begins talking about things a service management system should be interested in is about half-way through with "Keeping Track of Processes".

It spends roughly the rest of the document on important service management things, but to dismiss the idea that "systemd is about speed" is a myth is too much.

systemd IS about speed of booting -- during the development there were flame graphs showing how doing all this in parallel you could make the system boot really really fast. A lot of time was spent making the boot process with systemd minimal, or speedy.

Personally I'd prefer a less speedy service management system that didn't open listening sockets for my daemons so that it could deal with starting services out-of-order... to make the boot occur in a more parallel fashion... to make the boot faster.

No, that's revisionism, Poettering rewriting history.

Clearly you have missed this article: http://blog.darknedgy.net/technology/2015/09/05/0/

Reply on news.ycombinator.com