Just as the fabled Sherlock Holmes sought to understand a problem until he came to a conclusion, we have done the same with systemd. Many Linux administrators still do not fully understand the how and why of systemd, but they may know how to use it. In my latest course, "Mastering systemd", we worked to remove the fog around systemd so that we can better understand and use it. We found that systemd is no Hell Hound from the Baskerville Estate, but more of a trustworthy companion such as Dr. John Watson. Alright, I will lay off the Conan Doyle references for now.

A lot of research has gone into this course, perusing man pages, watching many presentations by the creators of systemd, and experimentation on what we can do with this new initialization system. I for one was quite excited to get this assignment as I have been working with systemd since its debut in the Fedora Linux distribution. At first, I admit, it was jarring trying to switch away from my old friends the chkconfig and service commands. As time went on, I got used to the new way of managing services. At the outset, I was confused as to how this new system worked under the hood, as many of the familiar init scripts that I had grown accustomed to were no longer there or really needed. Many of my fellow system administrators had just accepted the change and moved on, as so many of in the field of Information Technology lacked the time to really dive into the inner workings of systemd until we had to write our own unit files. Even then, we did not go much further past what was necessary to know about creating basic unit files for our services. In this course, however, we step beyond those basics to gain a better understanding of what those directives within a unit file mean, and how they work together. We even see how systemd simplifies the management of our operating environments (hello targets, goodbye runlevels).