Systemd as tragedy

> So, it exposes bugs on your systems that were ignored by other init.

We configured the other init to not have those problems. There's no packaged, working upgrade path from anything to systemd, so on upgrade every configuration knob we've ever set over the years instantly reverts to whatever the distro default is today, and that breaks a lot of stuff.

Some of the bugs are unique to systemd, i.e. if systemd didn't exist, we'd deterministically never have the problems. Other inits don't depend on non-default kernel behavior to the extent systemd does, so we hit problems that happen with test systems using systemd and nowhere else.

The original question was "what are the regressions?" so I just summarized the last decade of ways existing code can combine with systemd and fail (so far).

> > changes in error handling behavior (mount failure stops boot dead if the device is not noauto in fstab)
> As opossed to never noticing or getting ignored.

Those errors were intentionally ignored (by setting fsck pass field to 0, or using the 'bg' option for NFS). Absent and busted filesystems are a significant use case for us, so all the service applications we run handle it. 'mount -a' normally doesn't even try to mount if the device isn't present at all.