Good for you that you never experienced it breaking, because when systemd breaks, half the time the experience very much feels like breakage in a proprietary so

Good for you that you never experienced it breaking, because when systemd breaks, half the time the experience very much feels like breakage in a proprietary software stack (like Windows or, god forbid, Apple). Most recently, I've had systemd entirely prevent the mounting of an encrypted external HDD because the previous service it created for the mount (the previous time the disk was connected) refused to allow itself to be deactivated (even though there were no open handles left to either the disk or the mapper), and conversely knock a rental server offline (after an automated package upgrade from Debian security) as it decided that it didn't need to and wouldn't want to start network.target anymore. In neither case was there any diagnostic information available (in the journal or daemon status) that would provide pointers to why it behaved as it did, and unlike with an external daemon manager it doesn't seem easily possible to forcibly debug what exactly it tries to do when performing an action (without debugging the entirety of systemd, which probably would require a second machine in physical proximity or at least running the problematic system in a VM?). In the end, I still have no solution to the former problem (which occurs occasionally) other than doing a hard reboot; for the latter, I gave up and made a service (using the hoster's virtual console service) under a different target that performed the necessary ifupdown calls to make the server reachable again upon reboot. Neither of these are things that I remember having to do on Linux before this "enterprise-quality" technology was rammed down my throat; it really feels much closer in UX terms to patching out bugs in system DLLs with a hex editor back in the days.