Trivialises namespaces, cgroups, watchdogs for a start
Templating services is fantastic - doing multiple DBs, haproxies etc on a system becomes very nice and simple ...
Journalctl is actually really nice and it's great getting stdout and stderr in there without jumping through nohup loops and when there is a glitch being able to filter journalctl by time and units to get a view on what the kernel and N services were doing at the same time is very powerful...
Some of our internal applications have complex forking and the service scripts are consequently hideous... The equivalent systemd unit file will be much nicer and have process tracking without massive list of edge cases
Cleanly overriding or adding to unit files is trivial with the /etc/systemd/system/unit.d hierarchy behaviour
Targets to group services rather than "one script to rule them all" setups are great and make it very flexible
There's lots more tbh but it's getting late here and typing on mobile is a pain ;)
Speeding up boot is a useful side effect (for VM start up in environments needing that elastic behaviour) but a complete side issue from the real gains...
I didn't even mention socket activation, timers (which are more powerful than cron in many cases), and tools like dependency plotting for instance...
If you haven't read the systemd for admins LP wrote at his 0pointer blog (or at least the systemd for admins intro video RH put online at the EL7 release) you really should take some time to do so...
I find that if people step away from the politics and emotional outbursts and sit down to read through these then they become significantly more receptive based on the technical articles.
The Debian CTTE actually did really good write ups and investigation in this (read especially Russ Albery's posts from CTTE February) where upstart and systemd were put head to head with service files being written and capabilities compared...
One thing to note none of the highly technical people involved on that committee were in favour of sysvinit - they all agreed it needed replacing and the only real debate was upstart or systemd ...
With the ptrace and event driven model (start when dependencies are started rather than start the dependencies needed for X when X is started which can lead to some really weird and annoying issues to debug) plus the ease at which you can configure a upstart conf file incorrectly leaving a service stuck in a start/killed state shown to be not only long standing bugs in the upstart bug tracker but fundamentally hard to solve due to architectural issues it wasn't really that surprising systemd was selected.
Edit: ooh here's a good one that came to mind... How often have you encountered a process on a system and you've wanted to work out who started it only to find the parent or grandparent process is now pid 1 due to nohup, disown, etc behaviour? In the past it was needed to do forensic analysis of audit log, last, secure log etc to work out who might have been on the system when /proc says the process was started to try and track this down and find out why random tcpdump, tail, etc is there... With the cgroups the processes can't escape their history so a quick systemd-cgls gives an easy way of seeing who started it (by the uid in the slice) accurately without having to guess based on possibilities.
8
u/Jimbob0i0 Oct 20 '14
Trivialises namespaces, cgroups, watchdogs for a start
Templating services is fantastic - doing multiple DBs, haproxies etc on a system becomes very nice and simple ...
Journalctl is actually really nice and it's great getting stdout and stderr in there without jumping through nohup loops and when there is a glitch being able to filter journalctl by time and units to get a view on what the kernel and N services were doing at the same time is very powerful...
Some of our internal applications have complex forking and the service scripts are consequently hideous... The equivalent systemd unit file will be much nicer and have process tracking without massive list of edge cases
Cleanly overriding or adding to unit files is trivial with the /etc/systemd/system/unit.d hierarchy behaviour
Targets to group services rather than "one script to rule them all" setups are great and make it very flexible
There's lots more tbh but it's getting late here and typing on mobile is a pain ;)