CentOS 7: Take the Plunge into SystemD

CentOS 7, along with Kernel, Desktop, package and application changes galore, has taken the "Fedora" and "Debian" plunge into the deep end and converted daemon and service management from the older "service or /etc/init.d" paradigm into the "systemd" end of the pool. If you are a modern Linux Desktop user on a daily basis, you may be completely familiar with that method, however, it is a pretty large change for those administrators coming from the longevity associated with Red Hat and CentOS' use of the 'service' method of management. Let's take a deeper look at the new way of doing things. Why the Sudden Change? Well, to be overly simplistic, it was time. Now that our servers have graduated into the modern age where they are asked to do everything including make us dinner (well, maybe not that far yet), there were a whole lot of things that the older 'init' based systems (to be complete, the 'init' systems are technically grouped into the 'sysvinit' category to mark their compatibility with Unix System V from quite some time ago) are not very good at or require a lot of extra hacking around. Here are just a few of the things that systemd can do that are not supported under 'init' distributions:

• Read Ahead
• Socket Based Activation of Service
• Device Based Activation of Service (i.e. USB)
• System Snapshotting (Virtualization, ZFS, or otherwise
• SELinux Full Integration (Kernel level, not service level)
• Device Dependency Configuration (udev rules)
• Service Respawn without Connectivity Drop
• Service SSL Cert/LUKS Password Handling (including Console, wall and Gnome Agents)
• Interactive Bootup (Dependency Based with Confirmation of Service Start)
• Reliable Termination of User Sessions During Shutown
• Earlier BOOT Logging

This is a subset of what systemd offers and you can check out a more comprehensive list here for more information. How to Use It The easiest way to dive into systemd is to take a look at the commands that you use to manage your processes as an example. Let's say we want to see if the "sshd" service is running on CentOS 6 (or another 'sysvinit' distribution). We can issue the following command and see the result:sudo service sshd statussshd (pid 2095) is running... Great. We know it's running but not a whole lot else. Let's see how systemd handles that same query and the additional introspection it can provide: sudo systemctl status sshdsshd.service - OpenSSH server daemonLoaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)Active: active (running) since Sun 2014-08-03 16:08:44 CDT; 1h 11min agoProcess: 761 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)Main PID: 776 (sshd)CGroup: /system.slice/sshd.service└─776 /usr/sbin/sshd -DAug 03 16:08:44 centos7vm systemd[1]: Started OpenSSH server daemon.Aug 03 16:08:44 centos7vm sshd[776]: Server listening on 0.0.0.0 port 22.Aug 03 16:08:44 centos7vm sshd[776]: Server listening on :: port 22.Aug 03 16:44:26 centos7vm sshd[2191]: Accepted password for USER from 192.168.1.XX port 60818 ssh2 Wow! That's a bit more information than we got before without doing anything to find it except ask. Let's take a quick look at the new systemd commands and the equivalent sysvinit commands they replace: SYSTEMD SYSVINIT======= ========systemctl start httpd service httpd startsystemctl stop httpd service httpd stopsystemctl restart httpd service httpd restartsystemctl status httpd service httpd statussystemctl enable httpd chkconfig httpd onsystemctl disable httpd chkconfig httpd offsystemctl is-enabled httpd N/Asystemctl mask httpd N/A Now, in general, most modern distributions still "support" the older sysvinit way of doing things. You will see the following message though (for now) if you use the old way:sudo service sshd restartRedirecting to /bin/systemctl restart sshd.service Keep in mind that this support is not guaranteed to stick around and I suspect will eventually fade away. Make sure you know the new commands. Final Thoughts Sysytemd has been gaining the support of all major distributions since its creation in early 2011. The additional power and flexibility of managing your system this way will provide you with information and consistency of use that was missing before (notice that the same command is used to do everything, no switching back and forth between service and chkconfig for example). The transition is not terrible difficult until you begin installing your own services or want to change the default runlevel of your system. We will cover those topics in a future post. Leave a comment below with any questions or problems and we will do our best to help you out!