I have personally experienced a ton of breakage from systemd. The claim was that systemd was compatible with sysV init scripts. This is not true, and the brea

I have personally experienced a ton of breakage from systemd. The claim was that systemd was compatible with sysV init scripts. This is not true, and the breakage might not even be noticed until you are dealing with data corruption. If you have a startup script that does an su to a different user, systemd will start the application, but it will just kill the application processes that were spawned after the su, rather than doing a proper shutdown. E.g., if you use the startup script (only sysV) Oracle provided, systemd will kill your DB's processes in an apparently random order rather than allowing a proper shutdown. The issue is in the way systemd uses cgroups to keep track of which running processes are associated with a particular startup script. Every version of systemd is affected. Systemd initially claimed compatibility with fstab. But, it broke things. Systemd does not process the entries in fstab sequentially. This breaks fuse filesystem mounts that depend upon a backing store mount. Systemd later added additional mount options to try to hack around the breakage, but, in my experience with glusterfs, they are necessary, but not sufficient, and I had to add overrides for other systemd service units to get things to start reliably. I also had a fun time cleaning up the mess after systemd made remote systems using full disk encryption, unbootable. The responses by Poettering in the bug report from the Debian systemd maintainer were what really convinced me this systemd thing was going to be a huge mess. TLDR Poettering basically said, he never used a feature like Debian's keyscripts, and wasn't willing to make the existing system work. Years later Debian has a hack that allows keyscripts to unlock disks in the initrd before systemd gets involved in the boot. Another fun issue early on, on an embedded system that was using ext4 without a journal. The system experienced a hard power down. When it came back up, it prompted for a root password for the emergency (single user) shell. But, it wouldn't auth. It started echoing back parts of what were typed mixed in with garbage characters in its prompts (including the plain-text root password). Messing around in this state, I realized that it was executing (as root) whatever I typed as the password. So, for password, I typed fsck -f ... and was able to get the system bootable again. System was reverted to sysV, and everything worked properly again. Maybe this was a systemd-logind issue? I use systemd since it "won", but it has not been a good experience (the above is a small subset of issues I've personally seen, but pretty representative of impact).