I and multiple of my coworkers love systemd. We work in a "hyperscale" environment and we moved from sysvinit through Upstart to systemd at scale, predominantly

I and multiple of my coworkers love systemd. We work in a "hyperscale" environment and we moved from sysvinit through Upstart to systemd at scale, predominantly on RHEL and a little Debian. We were all skeptical at first. But sysvinit and Upstart both sucked for various reasons, and we had tried to work around the warts. systemd has mostly solved all of those problems for us. Some of the things that systemd improved: Init scripts suck to test and debug. When manually-called, the caller's environment would get used, rather than a clean env, which would cause problems with the poorer-quality scripts. These showed up multiple times in production where an engineer would bounce a process manually and it got some configuration from their environment. We took some steps to alleviate this, like encouraging use of `service`, but using the scripts directly was reflexive for most because of years of indoctrination and it's portability to some other operating systems. systemd eliminated this entire class of issues, because unit files are just config files, not scripts. Dependencies actually work. Usually, this came up when needing to wait on the network. With systemd, this is just a single dependency in the unit file. It also meant we stopped having to manage S## and K## which became something of a time-consuming art on machines with lots of services. Not exactly init system, but systemd's triggered units absolutely destroy cron. Manually running a job (e.g. when testing or when a run failed) guarantees the same environment, whereas cron has no similar capabilities. It also actually keeping status means we can more easily see if the last run succeeded. This may ease our monitoring burden, too, but we haven't gotten to give it attention yet.