Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Jan 27, 2013 12:11 UTC (Sun) by lkundrak (subscriber, #43452)
In reply to: Poettering: The Biggest Myths by hazard
Parent article: Poettering: The Biggest Myths

1) systemd is a solution for a problem that doesn't exist for me.

Be very thankful you're not me then!

root@megalodon# service postgresql start
Starting postgresql service: [  OK  ]
root@megalodon# su postgres -c "psql -c 'select 1;'"
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

For a good explanation how systemd solved problems that bothered me for years please refer to my posting above. Also, argument that most issues probably could have been solved by hacking the shell init scripts is indeed valid (some couldn't, like reliable shutdown via freezer which needs init system assistance at service startup time). Problem is that it would have been rather complex for certain problems, way more than can be legibly expressed in a shell script and leading to fragile and slow solutions (I'm pretty sure, I've seen too many of those).

2) Entire SysV based boot can be understood on the spot by reading the code of the scripts. Compared to this, systemd is a black box, to fully understand its internals you have to go outside the command line: hunt for the docs on the Web, download the source code.

Which system do you use, out of curiosity? I just tried to understand what could go wrong during a failed openldap startup by peeking at /etc/rc.d/init.d/slapd and found out that it seems to be a startup script for a nuclear power plant instead of a directory service.

3) systemd makes the boot process non-linear and complex to comprehend and predict. I cannot easily see the boot process visually as it is happening and I have to rely on external utilities to understand the order in which everything will be started. With systemd, I get a feeling that I'm booting Windows - I don't have a feeling that I'm in control anymore.

This is probably the same issue as (5): the learning curve. Speaking purely for myself, it does not take a lot of time to get comfortable with the utilities and the utilities are superb in cause something starts in an incorrect order (due to a missing dependency or something). Also, due to lazy activation it doesn't happen very frequently that things mess up.

4) systemd is more difficult to troubleshoot. Starting a SysV script, I get output and errors straightaway on the screen. With systemd, at best this information is hidden somewhere in the logs which I have to hunt for.

This is not true, maybe it improved significantly since you've tried systemd? Systemd now catches stderr output and you can easily inspect it with systemctl status when things fail, without fear that it will scroll away from your screen. This pleased me very much when I found out about it :)

5) systemd has a steep learning curve. There are lots of config files and interaction between them is not obvious. It'll be quite difficult to explain it to a junior system administrator.

It's probably easier to get a junior administrator write a robust and correct service file than write a robust and correct sysvinit script. He may probably not understand the inner working of the init system, but most juniors probably never peek at /etc/rc* either. Moreover, most juniors probably are not terribly curious about kernel internals, yet kernel delivers satisfactory "just works" experience to them. If systemd could do the same (it does for me!) it would probably be fine.

---

(Log in to post comments)