Over time I've accumulated all sorts of local init.d scripts on both my work and my home machines. With my move to Fedora 15 comes systemd, and I was recently prompted to try migrating my crufty old init.d scripts to today's new modern way of doing things.

(I'm a crazy person so sometimes I like doing things like this, not because I have any real need of it but because it just seems like the thing to do.)

I'll admit that when I first heard about systemd, I was more than a bit uneasy. systemd was yet another init system replacement when we were going through that already with upstart, but my big concern was that it was written by the primary author of PulseAudio. I've had a very rocky experience with PulseAudio, as have lots of people; PulseAudio updates (and associated kernel driver changes) are infamous for breaking working audio configurations and the PulseAudio developers are equally infamous for how they've dealt (or not dealt) with this. So I was not necessarily looking forward to a distribution based around systemd.

I was wrong. Pretty much all of the things that the systemd pages talks about are true, and in particular systemd service descriptions really are short, to the point, and easy to write. I converted pretty much everything I had easily, and it's been a pleasure to not have all of the boilerplate goo that infests init.d scripts. In several cases I could simplify how I ran programs because I didn't need to carefully daemonize them any more or jump through hoops to run them as a specific user.

(And it really seems to work for speeding up boot times.)

This isn't all that systemd offers a sysadmin. For a start, systemd can tell me what a particular daemon process belongs to, which is invaluable for answering questions like 'okay, what started this gpsd process that thinks my modem's serial port is a GPS unit?' (sadly that was a real question I had today). There are other potential benefits, although I haven't explored them in depth so far.

Overall, my decided impression is that the authors of systemd have really tried to think about what sysadmins want and need to do on their systems, and built mechanisms where they can do this well, in ways that cooperate with the rest of the distribution. For example, that systemd looks in /etc/systemd/system for service descriptions before /lib/systemd/system means not only that you can customize services but that you can do so without running into package manager issues.

(systemd is not without things that I wish were different, but that's another entry.)