[arid_eden]

The post was on 'the good parts' of systemd, so complaining about balance seems unfair. I will call out one aspect that the author deemed a 'good part' as in my experience its a bad part: journald.

Usability: journald requires administrators to learn a new command to access their journals - everytime I have to use it I need to look up the syntax again. Compare with logs in /var/log and you can use all the standard unix tooling (text editors, tail, grep etc).

Reliability: in my use journald has made my servers more unreliable. Two CentOS 7 VMs, setup at the same time. On one journald works just fine, on the other approximately once a month journald would stop logging. It wouldn't start logging again until you noticed and rebooted the server. The real issue this exposes is that on a systemd machine, journald doesn't just log for itself, it also supplies the logs to syslog. So on this server when journald broke, there were no logs whatsoever.

This issue was apparently common on the version of systemd shipped with CentOS 7. The fix was to disable log compression in journald. What it highlighted to me was the inherent issues in an all encompassing system controller like systemd, in that if there is a bug somewhere in there you lose not only the added bells-and-whistles its intended to provide (journald in this case) but also the old previously reliable functionality (syslog).

In my mind the fix for this is a redesign of systemd to make it an optional layer on top of the reliable functionality rather than a low level system component that everything else needs to depend on. In the case of logs journald should consume logs from syslog, not provide them to syslog.

[kaba0]

Aren’t you assuming way too much on the architecture of systemd with only a surface level knowledge?