systemd is new service manager for linux. it’s a replacement for all previous init systems (sysv/sysvinit & ubuntu’s upstart) and can manage system startup and services. it starts up and supervises the entire system. in the article we are using centos 7.0 installed with systemd 216 version and the latest version is available for download from freedesktop.org. since 2015, the majority of linux distributions have adopted systemd and it is considered a de facto standard. the name systemd adheres to the unix convention of naming daemons by appending the letter d. it also plays on the term “system d”, which refers to a person’s ability to adapt quickly and improvise to solve problems.
in this article, i will show you how to use systemctl to manage systemd service in linux.
when working with systemd, it is important to understand the concept of units. units are the resources systemd knows how to interpret. units are categorized into 12 types as follows −
for the most part, we will be working with .service as unit targets. it is recommended to do further research on the other types. as only .service units will apply to starting and stopping systemd services.
each unit is defined in a file located in either −
- /lib/systemd/system − base unit files
- /etc/systemd/system − modified unit files started at run-time
pid 1 is occupied by “systemd” and can be seen from pstree command as well:
let’s explore what systemd is capable of and what possibilities we have with the new replacement for sysvinit.
1) faster startup
the sysvinit starts the processes serially, one at a time. systemd starts services in parallel and starts only those services which are actually required, reducing the boot time significantly.
you can get the boot process duration with the following command:
the command systemd-analyze time also shows the same information.
if you want to print a list of all running units, the blame option to systemd-analyze command can provide you with that, ordered by the time taken to initialize.
the above screen shows only a small number of processes, you can scroll through the list with arrows just like in less pager.
2) systemctl command
the systemctl command is the most talked command that comes with systemd. you can manage a whole lot of your system with this command. let’s explore this command before going any further:
systemctl command without any option lists all the running units. the list-units switch also does the same.
listing failed units
the failed units can be listed with –failed switch.
you will see the use of systemctl command at many places in this article.
3) managing services
let us now see how services can be managed with systemd.
all the active services can be checked with the following command:
systemctl list-units -t service
in the sysvinit, we could use the “service” command to manage the services, but with systemd, the systemctl command is used to manage services. in ordwer to see whether a service is running or not, we can use the systemctl command like this:
systemctl status dnsmasq
start a service
to start a service, again we use the systemctl command as:
systemctl start dnsmasq
as opposed to service command, this command does not give any output. but of course, we can check the status of the service once again to confirm that its started successfully:
stopping a service
now you are smart enough and already know the command to stop a service with systemd:
systemctl stop dnsmasq
restart a service
similarly, restarting a service is managed using ‘systemctl restart ‘:
systemctl restart dnsmasq
reload a service
in case we need to reload the configuration of service (say ssh), without restarting it, we can use the command:
systemctl reload sshd
although all of the above syntax is working, the official documentation suggests that these command be run with the following syntax:
systemctl status dnsmasq.service
4) managing services at boot
the chkconfig command was used to manage services at boot. the same command systemd is used with systemd to manage services at boot.
checking service status at boot
in order to check if a service is enabled on boot or not:
systemctl is-enabled dnsmasq.service
enable a service at boot
systemctl command can be used like this to enable a service at boot (this corresponds to sysvinit ‘chkconfig on’)
systemctl enable dnsmasq.service
disable a service at boot
similarly, the services can be disabled at boot with systemctl command:
systemctl disable dnsmasq.service
5) managing remote systems
typically, all of the above systemctl commands can be used to manage a remote host with systemctl command itself. this will use ssh for communication with the remote host. all you need to do is add the user and host to systemctl command like this:
systemctl status sshd -h [email protected]
6) managing targets
systemd has a concept of targets having a similar purpose to runlevels in sysvinit.
the runlevels in sysvinit were mostly numeric (0,1,2,…). here are the runlevels in sysvinit with their systemd counterparts:
0 runlevel0.target, poweroff.target 1, s, single runlevel1.target, rescue.target 2, 4 runlevel2.target, runlevel4.target, multi-user.target 3 runlevel3.target, multi-user.target 5 runlevel5.target, graphical.target 6 runlevel6.target, reboot.target emergency emergency.target
changing current target
the current target(runlevel) can be changed with the command:
systemctl isolate graphical.target
list current target
if you want to see what target you are in, you need to list all the corresponding units. it might not feel at home with this new way, but its the way systemd works.
systemctl list-units --type=target
you can see “graphical.target” listed here. this is what we changed our target into. now let’s change the runlevel again to multi-user.target and then analyze this output:
systemctl isolate multi-user.target # systemctl list-units --type=target
list default target
to list the default target, we use systemctl command like this:
change default target
the default target can be set with set-default command with systemctl:
systemctl set-default graphical.target
7) logging in systemd
the systemd has its own logging system called journald. it replaces the syslog daemon from sysvinit. the command journalctl is used to read the logs.
to see all boot messages, run the command “journalctl -b”.
[[email protected] ~]# journalctl -b
the following command follows the system logs in real time (similar to tail -f).
[[email protected] ~]# journalctl -f
service specific logs
to check logs specific to a particular service or executable, use journalctl like this:
[[email protected] ~]# journalctl /usr/sbin/dnsmasq
8) power management
the systemctl command can be used to put the system down, or reboot or hibernate.
to poweroff, reboot, suspend and hibernate, use the following commands respectively:
systemctl poweroff # systemctl reboot # systemctl suspend # systemctl reboot
9) hostnamectl command
the systemd brings out the whole new approach to interacting with your operating system. the systemd is so full of features. for example, you can get the hostname and other useful features about your linux machine, you can use hostnamectl command
[[email protected] ~]# hostnamectl