Comment by adrian_b | Hacker News Reader

Comment by adrian_b | Hacker News Reader

Parent Full thread

Before using SystemD for the first time, I also wondered if there is any grain of truth in what its opponents said about SystemD.

However, after trying SystemD for one week, I became convinced that the designers of SystemD are incompetent, so they cannot be trusted with a component of such importance for a computer.

I am normally a Gentoo user, but a few years ago I wanted to install Linux in a hurry on a small computer. With a slow CPU installing Gentoo can take several hours, unless you have a previously prepared image, so I decided to try ArchLinux.

The installation was indeed fast and without problems. However, SystemD behaved in an unexpected way. SystemD is advertised as booting quickly. It indeed booted quickly, but no faster than my optimized Gentoo systems.

On the other hand the shutdown with SystemD was very slow. This was a huge surprise, because never before and never after have I encountered any computer where the shutdown is annoyingly slow.

Moreover, sometimes the shutdown FAILED, which is also something that I have never encountered on any computer not using SystemD, and I have used thousands of computers, with many kinds of operating systems, including at least eight or nine UNIX flavors other than Linux.

The failure of shutdown was apparently due to some kind of race condition when some process was killed faster than some SystemD component expected and that SystemD component was still trying to communicate via DBUS with the defunct process and it blocked because its messages no longer reached the destination.

I suppose that this bug might have been corrected eventually, but this is a design error that I consider unforgivable, i.e. to conceive a shutdown sequence which depends on successful inter-process communication.

After seeing such a mistake I have lost any confidence in the abilities of the SystemD developers, so I have never tried it again.

The more you have to deal with systemd, the more you hate it. I wrote maybe two dozens of unit files at this point and can't take seriously any praise of systemd anymore, I immediately assume such people don't actually do anything with it beyond starting and stopping services.

I don't mind systemd and I've administered a lot of stuff with it at this point, well beyond just start/stopping services -- I've written plenty of unit files, written drop-in unit file overrides, written timer units, written auto-mount units, looked at startup timing profiles, debugged issues using journalctl, etc.

If I had to guess, it's probably because I've never ran into any of the weird systemd problems that I see people report sometimes. For me, it's always pretty much just worked, and more often than not it natively has the functionality that I want.

My largest complaint is that I have to bounce across several manpages to write a comprehensive unit file.

For the long shutdowns, you probably want to make the `DefaultTimeoutStopSec` config shorter, so that systemd doesn't wait as long for services to stop before sending them a SIGKILL.

Do you count signals as inter-process communication? I'd argue they are, and the init system definitely needs to cleanly shut down the system (using signals, at least). What degree of inter-process communication is acceptable, then?

Not OP, but I would consider SIGTERM as IPC, but SIGKILL as not really IPC (since the target can't respond to it).

Traditional RC does a SIGTERM to everything, and then waits a bit and then does a SIGKILL to everything. This means that if the SIGTERM failed to be handled properly, progress is still made.

systemd does that too. The problem is that the default wait time is insanely long (I think it is something like 5 minutes). My biggest complaint with systemd is the same as my biggest complaint with tmux: many of the defualt configurations are very strange.

Yeah, default configuration of systemd-logind is to prevent network access. This means if you use e.g. NIS authentication weird things happen.

Weird as in 3 minutes after someone SSHd into my workstation, X11 restarted. Until I tracked it down to a default systemd configuration I thought I was going insane.

Beyond the default configuration, which is somewhat defensible as NIS is probably not a typical case, it really bothers me that if someone else's login process has issues, everybody's logins get killed.

Reply on news.ycombinator.com