&gt; I am still to find a sys admin that likes systemd.<p>Here&#x27;s another one: I spent 18 mos in Google Site Reliability Engineering (and did a lot of pager work at startups before that) prior to transferring to software engineering, I think I can speak to both perspectives.<p>Systemd is incredible and is a huge advance in maintaining linux systems. It boggles my mind that anyone could compare it to what we were all doing before and walk away saying: &quot;nah, I&#x27;ll stick with the stringly-typed shell scripts and the stale pid files, thanks.&quot;<p>Specific technical reasons in favor &#x2F;for sysadmins&#x2F;:<p>- unit files are rigidly structured data and this is a Good Thing. Configuration is not code. Unit files are also very easy to write.<p>- systemd understands cgroups and manages them properly. Every single critique I&#x27;ve seen of systemd is from someone who either doesn&#x27;t understand cgroups or doesn&#x27;t realize why they are so useful and important. Cgroups manage jailing, process isolation, resource control (CPU shares, memory limits, block io shares, etc), privilege separation and dropping, etc., and this is all configurable by systemd using simple and declarative unit file directives. Like it or not, we are moving into a containerized world.<p>- machinectl is already useful for managing VMs and will only become more so as it matures.<p>- people shit on the systemd journal, but, I&#x27;m sorry -- you&#x27;re wrong about this too. Structured binary logging is simply more efficient for this problem, both on the write and on the query side. The journal also can integrate with the systemd journals running in any VMs or containers running on your system, so you can get a unified and metadata-tagged logging stream of everything happening on the host<p>- socket activation enables zero-downtime restart&#x2F;deployment for network services, any incoming connections to the port will be added to the listen queue by systemd before the target system comes back online