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 status
sshd (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 sshd
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Sun 2014-08-03 16:08:44 CDT; 1h 11min ago
Process: 761 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 776 (sshd)
CGroup: /system.slice/sshd.service
└─776 /usr/sbin/sshd -D
Aug 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 start
systemctl stop httpd service httpd stop
systemctl restart httpd service httpd restart
systemctl status httpd service httpd status
systemctl enable httpd chkconfig httpd on
systemctl disable httpd chkconfig httpd off
systemctl is-enabled httpd N/A
systemctl 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 restart
Redirecting 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!

Hands-On Linux Training

Terrence T. Cox

A veteran of twenty years in Information Technology in a variety of roles. He has worked in development, security and infrastructure well before they merged into what we now call DevOps. He provides training in Linux, VMWare, DevOps (Ansible, Jenkins, etc) as well as containers and AWS topics.

Leave a Reply

Your email address will not be published. Required fields are marked *