> Most of the problems with systemd stem from not knowing or not caring about how to use it
I think that's a little unfair, but, that said, the very presence of systemd on a system can also lead to a systemd blinker coming down when troubleshooting.
I actually spent some time dealing with an issue earlier. For some reason systemd-udevd had started deciding to rename a NIC from it's configured name to "rename2".
I'm sure Lennart's ears were burning for a little while, until I looked a little closer and remembered what fuckwits Realtek are.
The NIC in question is part of a bond, and on the reboot just before the issue, systemd got impatient waiting for the network to come down cleanly, so just shut it off. On boot, the RTL driver reads the MAC from the NICs volatile storage (instead of the PHY) so got the bond's IP instead, which of course matches the other slave. So two NICs matched the same udev rule...oops
Blaming the (sometimes) clusterfuck that is systemd is too easy and rarely solves the problem itself.
But systemd isn't faultless either, just as some distros managed to ship flawed selinux configs (apache context? Nah, won't need /var/www/html). It's got it's problems and journalctl is a fair example (system hung and want to know why? Sorry the binary log is corrupted). Being able to pass through to rsyslogd is a bandaid not a fix for the issue
Or, as others have pointed out, the NTP issues.