Hacker News Reader

Comment by mjevans | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com