What does systemd do anyways?

It’s a collection of unrelated software mashed up together, yet without much meaningful integration.

Logs are stored in a binary format of custom specification:

  • It is great for filtering, joyrnalctl is much better than a long chain of grep | sed | cut | whatever, and uses internal tags rather than string regex.
  • It is useful to just browse around through logs, but when the system crashes? File is corrupted.
  • It, despite being a great concept, fails right where it’s needed the most.

Reinventing /home

  • Great, but why a daemon? Why not call the helper systemd-homework via PAM itself or whatever?
  • After so much for “portable across systems”, how exactly is that achieved? It tags the machine-id and refuses to accept the new image on other systems, unless ugly hacks are followed.
  • It slows down the startup and shutdown, for some reason… (even a cobbled-up bash script does the process faster; It’s just flush-to-disk, sync, unmount, un-unlock/lock, un-(device-)map, reflush, exit)

inetd in PID-1

Well, this has it’s own serious implications. Mainly, it now requires heavy libraries to be pulled in by the PID-1 binary.

poweroff doesn’t work if an openssl library is missing/corrupted…

Well, this is true, I have experienced this. The boot failure next day because I forcefully powered-off, is also caused by this.
Please, let the core system components be free of all this.

Whatever is chase() in libsystemd

systemd-tmpfiles fails to run because some mount is not they way systemd likes (Like in a chroot + unshare).
AND udevd, and many other things

What else?

I like systemd, it’s great. But the issues…

1 Like

Interesting take. You’ve clearly spent time digging into this — mind sharing your setup or a specific case where journalctl failed you? Curious how reproducible some of this is.

I have since made my logs be saved into some syslog daemon (rsyslog or syslog-ng IDK, I just cat | grep | sed | cut | awk | whatever on /var/log/messages…)

Yes, but I still save binary logs for my log-browsing pleasure…

Basically, when the system crashes (or whatever happens that the binlogfiles aren’t "clean"ly saved), journalctl ignores the logfile at worst, at best quite a few expected loglines are lost.
In any case, the final loglines are corrupted (strings ${binarylogfile} gives an extremely ugly output, but clearly a lot of output is corrupted…)

I use gentoo, KDE profile, with systemd of course.

Also, although file ${binarylogfile} says that the logfile is compressed and signed, the actual compression ratio is non-existent.
When I do a journalctl -i ${binaryfile} -o verbose | tee journal-o.txt and compare the dump with the direct size of the binaryfile, there was a significant difference. That with the text file non-compressed. The textfile was significantly smaller.

Do take this with a grain of salt. That was quite a few months ago, and now I haven’t checked if anything is improved…