Image may be NSFW.
Clik here to view.
This is the first of two Essential Linux Skills for CentOS blogs (see part 2). For many years I’ve become used to using service and chkconfig commands to manage services with RHEL (RedHat Enterprise Linux) and CentOS. In fact I first got my hands on a Unix system back in 1993, then got my first ever job as a Unix admin in 1996. I learned about SystemV runlevels, and then became used to using /etc/init.d/<service> to manage services. It takes a while to shake bad old habits, but CentOS 7 now uses systemd as the default init system.
Init (short for initialization) was the first process to start and the last to stop on a SysV (System V Unix) Linux system, and therefore we have the concept of runlevels. Each runlevel represents the state of the system, with runlevel 0 being shutdown (halt), 3 being multiuser mode (in other words it has now booted), and runlevel 5 is running the desktop environment if you use one (X Server starts and you have a desktop). Oh and runlevel 6 restarts the system.
Why is this important? Well, whether you like it or not, having core Linux skills is essential in the IT world we live in. In fact just a few weeks ago I was presenting at VMworld in San Francisco on VMware Horizon for Linux Virtual Desktops technical deep dive. I was approached after the session by a customer that has a project to deploy RHEL virtual desktops to hundreds of students in a college. He thanked me as he had to go home the following week to configure some of those virtual desktops with direct pass-through to NVIDIA GRID graphics cards. The process of doing that requires installation of the driver at runlevel 3, but he had no idea what it meant despite it being a simple command (init 3). It also meant that he learned about how to optimize RHEL by disabling unnecessary services that start at runlevel 3.
At VMware I see more and more customers deploying Linux desktops, but also server workloads are often running Linux (such as the server hosting this blog!), and virtual appliances.
SysV is still present on CentOS 7, but you’ll not find much there. If you run the following command, you can see which services are enabled at boot (runlevel 3).
# chkconfig --list | grep on
This will only show SysV services (for example, netconsole and network). You can also check the /etc/init.d/ directory.
systemd
Instead of /etc/init.d/ we now have /etc/systemd/system/. If you have a peek in there you’ll find our systemd targets and the symbolic link for default.target. These are what we know as runlevels, so just like we avoid watching old episodes of Friends, we’ll avoid using the term runlevel from now on!
drwxr-xr-x 2 root root 4096 Jul 7 2014 basic.target.wants lrwxrwxrwx 1 root root 44 Jul 7 2014 dbus-org.freedesktop.Avahi.service -> /usr/lib/systemd/system/avahi-daemon.service lrwxrwxrwx 1 root root 46 Jul 7 2014 dbus-org.freedesktop.NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service lrwxrwxrwx 1 root root 57 Jul 7 2014 dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service lrwxrwxrwx 1 root root 37 Jul 7 2014 default.target -> /lib/systemd/system/multi-user.target drwxr-xr-x 2 root root 4096 Jul 7 2014 default.target.wants drwxr-xr-x 2 root root 4096 Jul 7 2014 getty.target.wants drwxr-xr-x 2 root root 4096 Sep 12 10:57 multi-user.target.wants drwxr-xr-x 2 root root 4096 Jul 7 2014 sockets.target.wants drwxr-xr-x 2 root root 4096 Jul 7 2014 system-update.target.wants
The two targets we’ll focus on are multi-user.target and graphical.target which are essentially runlevel 5 (oops I said it again, sorry). In our case we haven’t installed a desktop environment so we’re just concerned with multi-user.target (our default target).
You can list all the currently loaded targets using the following:
# systemctl list-units -t target
Each service has 3 states; enabled, disabled or static. If a service is enabled it will start at boot. Static means it is typically dependent of other services and are controlled automatically.
To list enabled services use the following:
# systemctl list-unit-files --type=service | grep enabled
auditd.service enabled avahi-daemon.service enabled chronyd.service enabled crond.service enabled dbus-org.freedesktop.Avahi.service enabled dbus-org.freedesktop.NetworkManager.service enabled dbus-org.freedesktop.nm-dispatcher.service enabled getty@.service enabled httpd.service enabled irqbalance.service enabled microcode.service enabled NetworkManager-dispatcher.service enabled NetworkManager.service enabled rsyslog.service enabled sshd.service enabled sysstat.service enabled systemd-readahead-collect.service enabled systemd-readahead-drop.service enabled systemd-readahead-replay.service enabled tuned.service enabled
When a service is enabled it creates a symbolic link, usually at our multi-user target: /etc/systemd/system/multi-user.target.wants. Let’s take a look at this directory and we can see the symbolic links:
# cd /etc/systemd/system/multi-user.target.wants
# ls -al
lrwxrwxrwx 1 root root 38 Jul 7 2014 auditd.service -> /usr/lib/systemd/system/auditd.service lrwxrwxrwx 1 root root 44 Jul 7 2014 avahi-daemon.service -> /usr/lib/systemd/system/avahi-daemon.service lrwxrwxrwx 1 root root 39 Jul 7 2014 chronyd.service -> /usr/lib/systemd/system/chronyd.service lrwxrwxrwx 1 root root 37 Jul 7 2014 crond.service -> /usr/lib/systemd/system/crond.service lrwxrwxrwx 1 root root 37 Sep 12 10:57 httpd.service -> /usr/lib/systemd/system/httpd.service lrwxrwxrwx 1 root root 42 Jul 7 2014 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service lrwxrwxrwx 1 root root 46 Jul 7 2014 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service lrwxrwxrwx 1 root root 40 Jul 7 2014 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target lrwxrwxrwx 1 root root 39 Jul 7 2014 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service lrwxrwxrwx 1 root root 36 Jul 7 2014 sshd.service -> /usr/lib/systemd/system/sshd.service lrwxrwxrwx 1 root root 39 Jul 8 2014 sysstat.service -> /usr/lib/systemd/system/sysstat.service lrwxrwxrwx 1 root root 37 Jul 7 2014 tuned.service -> /usr/lib/systemd/system/tuned.service
To list all services, and the state and description of the service use:
# systemctl list-units --type service (add --all to show services loaded but inactive)
To start/stop/restart services you can still use service, but the new command is:
# systemctl status <name>
# systemctl stop <name>
# systemctl start <name>
# systemctl restart <name>
Practice
So let’s experiment with installing NTP with yum, checking the service status, starting it then enabling to start at boot (multi-user target).
# yum install ntp
# systemctl list-units --type service --all | grep ntp
You’ll now see from the following that NTP is loaded but not active (I’ve added the headings in for clarity):
UNIT LOAD ACTIVE SUB DESCRIPTION ntpd.service loaded inactive dead Network Time Service ntpdate.service loaded inactive dead Set time via NTP sntp.service not-found inactive dead sntp.service
# systemctl status ntpd
# systemctl start ntp (if it’s not already running)
Let’s see if it’s running now:
# systemctl list-units --type service --all | grep ntp
UNIT LOAD ACTIVE SUB DESCRIPTION ntpd.service loaded active dead Network Time Service ntpdate.service loaded inactive dead Set time via NTP sntp.service not-found inactive dead sntp.service
We don’t need to include .service (ntpd.service) as systemctl will assume it’s a service you are specifying anyway.
Enable the service to start a boot:
# systemctl enable ntpd
Check again to see which services are enabled, and ntpd should now be listed:
# systemctl list-unit-files --type=service | grep enabled
You have now mastered systemd and can impress your friends with your elite systemctl command skills! Image may be NSFW.
Clik here to view.
The post Essential Linux Skills with CentOS 7 – Managing Services with systemd appeared first on Ray Heffer.