The Grumpy Editor's guide to surviving the systemd debate

For the record, the problem with dracut was that it has a systemd 'generator' which only creates the important files the first time it is run: rootfs-generator.sh

When you "systemctl daemon-reload", systemd will remove everything from /run/systemd/generator and then re-run all the generators. As rootfs-generator.sh only created files in that directory the first time it is run, a subsequent 'systemctl daemon-reload' will revert the effect of that generator.

The key effect of the generator is to disable systemd timeouts on the device which holds the root filesystem - as dracut has its own timeout mechanism. So a 'daemon-reload' will re-instate the default timeout.

When dracut does timeout waiting for the md array to assemble, and forces the assembly of all degraded md array, it also runs "daemon-reload" (as part of giving up on resume-from-disk). This will cause systemd to give up on the root device immediately, typically a second or so before it is actually ready.

Does that make sense? Anyway, the primary problem was not a problem with systemd ... except...

The real goal of dracut here is to generally disable the systemd timeouts which wait for devices. Lots of systemd is configurable at runtime using systemctl, but this thing isn't. It can only be configured in /etc/systemd/system.conf before systemd starts. 'daemon-reload' doesn't reload system.conf.

So dracut has this complex (and buggy) code to over-ride timeouts that systemd doesn't let it configure in a sensible fashion. So maybe systemd is partly to blame, after all...