Systemd as tragedy

Posted Feb 3, 2019 13:48 UTC (Sun) by judas_iscariote (guest, #47386)
In reply to: Systemd as tragedy by zblaxell
Parent article: Systemd as tragedy

> assorted filesystem failures (filesystems don't mount, get mounted rw, get mounted in the wrong place, get stuck because DNS isn't up yet, get stuck because network down, mount with wrong flags, mount in multiple places, expose wrong filesystems to chroots, doesn't fsck, fscks with wrong flags)

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

> assorted network failures (firewall rules not established before devices up, devices up when they shouldn't be, devices not up when they should be, unwanted DHCP, unwanted autoconfigured IP addresses, firewall rules broken by network device name changes)

Systemd does not set the firewall up, another component does and unless you are using explicitly using systemd-networkd it does not setup network interfaces other than "lo".

> 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.

> changes in power management behavior (responds to previously deconfigured inputs, suspend loops, triggers buggy firmware, ignores existing PM configuration)

Yes, it does respond to previously deconfigured inputs... I do not know about what suspend loop are you talking about.. neither why you think bugs in firmware have anything to do with systemd.. and what do you mean with existing "PM configuration" .. do you mean runtime configuration that was set with a bunch of mostly useless shell scripts from pm-utils are no longer ran ? this is a distribution policy thing. Most if not all the power management configuration are kernel knobs and usually the kernel sets no policy whatsoever by default.

> package installation failures ('apt-get install random-package' blows up dependency resolver, packages conflict at runtime, init crashes during the upgrade and panics the kernel, system left unbootable)

Well.. packages are not part of systemd...for the start.

> missing dependency information is now a RC bug (systemd picks an execution order different from the order used for the previous decade)

Missing dependency information will make obvious what in the previous system was that "funny" ocurrence that caused service to fail on a particular phase of the moon.. as you probably already know, rc scripts are provided by the particular distribution you are using and are incompatible with others.

> miscellaneous data loss (cgroup service kill behavior for ssh, wipes /tmp on boot, backups fail due to not enough mounts or fill up disk because too many)

cgroup service kill behaviour is configurable..and better than it was before. (i.e there was none, if you were lucky things started correctly and that's it). /tmp wiped on boot is configurable and a distribution policy issue..

* different cgroup controller organization (broke cgroup management code, caused a few host crashes and a lot of performance losses)

Not sure what that means at all.

Systemd as tragedy

Posted Feb 5, 2019 16:49 UTC (Tue) by zblaxell (subscriber, #26385) [Link]

> 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.