Came across this YouTube video recently <https://www.youtube.com/watch?v=S9YmaNuvw5U> from the Red Hat Summit a couple of years ago, which gives a good intro to systemd, with Lennart Poettering as co-presenter. The video explains what a “service” is, and compares how much simpler it is to define a service (usually just a few lines of declarative config) versus the hundreds of lines of shell script it typically takes to set things up under the ancient sysvinit system. Not only that, but it is possible to customize the standard service definitions without having to copy and paste the entire existing definition file: you just create a few lines of additional/overriding definition in a “drop-in” file that you place in /etc, that matches the name of the original service definition. There is even a command, “systemd-delta”, which lets you immediately see all the places where your entire systemwide configuration has been so customized. Lennart mentions that speeding up boot was never a specific design goal, it just naturally came out of the parallelization of service startup. Because systemd lets you think in terms of “services” rather than “processes”, it achieves something that was difficult to ensure before, namely reliable shutdown of a service. Consider Apache, which typically spawns a whole lot of processes, and then if you run CGI scripts, they require additional processes. Nevertheless, shutting down httpd.service with systemd will ensure that all those processes are terminated. Another important feature of systemd is the logging. Here again systemd had a goal of achieving something that was difficult before, namely capturing all log messages from the earliest possible stages of the boot process, including the initrd stage. And also because the systemd journal mechanism has access to kernel information about the processes doing the logging, it can include information in the log entries that those processes cannot forge. Me, I like the fact that the log timestamps are stored in UTC, so you can display them in whatever timezone you wish. There is more, of course: “slices” are how systemd is able to strictly limit the resource usage of services (important to the RHEL-using, Java-suffering audience), and “sockets” are how the functionality of inetd/xinetd is carried over to the systemd world, so that services can be started on demand, instead of having to run all the time. Watch the video to learn more.