How Debian managed the systemd transition

If you do an exec() and it fails from some corruption of the page tables, or the executable at the wrong time without going through the file system (since you get -ETXTBUSY when trying to do anything with an executable file while a process is mid-exec on it), then the process is killed with an inescapable SIGKILL.

This is relevant for systemd, as there's a few circumstances where systemd will exec.

1. When shutting down it exec's systemd-shutdown, which primarily exists so that PID1 isn't holding files open and preventing a clean unmount.
Though a failure here is unlikely to ruin anyone's day too badly, since they were already shutting the box down, they just get a mystifying kernel stack trace on shutdown in the rare case where exec fails.
2. A suitably privileged user invokes `systemctl daemon-reexec`, which instructs systemd that it should serialise its state and exec itself again.
This is so that after a software update, systemd can use the new versions of dependent libraries, rather than the old ones that may have been removed, but systemd would still be holding open.
3. Privileged users may also request a `systemctl switch-root`, which is primarily intended for the initramfs transition, but could be used to move your rootfs to different storage (so long as you don't mind that most of your processes are killed).
In this case there's few processes hanging around to be able to break the executable mid-exec, but systemd supports the notion of "storage daemons", which are processes explicitly out of systemd's control, and are expected to have been exec'd from the initramfs.
If you are using a storage daemon to run a fuse-based rootfs then it could easily corrupt the executable mid-exec.

It has a big advantage over the current scheme: you can start it early and still don't need to worry about restarting it. It has no advantage over kdbus in terms of where the code is loaded from or ease of initialization, but I don't think it has a disadvantage either.

AIUI, the current scheme comes from the idea that all userspace code running after startup must reside on a non-initramfs mount. I've heard people say that it's not even possible to keep an initramfs program running after pivot_root. This is simply incorrect. Back when initramfs was actually ramfs, it wasted unpageable memory (just like kernel code), but initramfs is tmpfs nowadays.

Heck, there's no fundamental need for systemd to re-exec itself after pivot_root either, although, given that daemon-reexec is well-supported, it's probably a good idea from a forced testing and memory conservation perspective.

As a concrete, if dubious, benefit, udevd really could depend on dbus even without kdbus. Just require that dbus-daemon be started before udevd. (If this happened, I would drop udevd as part of the virtme minimal guest and I'd seriously consider busybox's udev as an alternative, but that a bit off-topic.)