How To Use Systemctl to Manage Systemd Services

How To Use Systemctl to Manage Systemd Services

Systemd Intro

Systemd is an init system and system manager that is widely becoming the new standard for Linux machines. While there are considerable opinions about whether systemd is an improvement over the traditional SysV init systems it is replacing, the majority of distributions plan to adopt it or have already done so.

Due to its heavy adoption, familiarizing yourself with systemd is well worth the trouble, as it will make administering servers considerably easier. Learning about and utilizing the tools and daemons that comprise systemd will help you better appreciate the power, flexibility, and capabilities it provides, or at least help you to do your job with minimal hassle.

In this guide, we will be discussing the systemctl command, which is the central management tool for controlling the init system. We will cover how to manage services, check statuses, change system states, and work with the configuration files.

Please note that although systemd has become the default init system for many Linux distributions, it isn’t implemented universally across all distros. As you go through this tutorial, if your terminal outputs the error bash: systemctl is not installed then it is likely that your machine has a different init system installed.

Systemd Management

For service management tasks, the target unit will be service units, which have unit files with a suffix of .service. However, for most service management commands, you can actually leave off the .service suffix, as systemd is smart enough to know that you probably want to operate on a service when using service management commands.

Restarting and Reloading

To restart a running service, you can use the restart command:

 sudo systemctl restart application.service

If the application in question is able to reload its configuration files (without restarting), you can issue the reload command to initiate that process:

 sudo systemctl reload application.service

If you are unsure whether the service has the functionality to reload its configuration, you can issue the reload-or-restart command. This will reload the configuration in-place if available. Otherwise, it will restart the service so the new configuration is picked up:

 sudo systemctl reload-or-restart application.service

Enabling and Disabling Services

The above commands are useful for starting or stopping commands during the current session. To tell systemd to start services automatically at boot, you must enable them. To start a service at boot, use the enable command:

 sudo systemctl enable application.service

This will create a symbolic link from the system's copy of the service file (usually in /lib/systemd/system or /etc/systemd/system) into the location on disk where systemd looks for autostart files (usually /etc/systemd/system/some_target.target.wants. We will go over what a target is later in this guide).

To disable the service from starting automatically, you can type:

 sudo systemctl disable application.service

This will remove the symbolic link that indicated that the service should be started automatically.

Keep in mind that enabling a service does not start it in the current session. If you wish to start the service and enable it at boot, you will have to issue both the start and enable commands.

Checking the Status of Services

To check the status of a service on your system, you can use the status command:

 systemctl status application.service

This will provide you with the service state, the cgroup hierarchy, and the first few log lines.

For instance, when checking the status of an Apache server, you may see output like this:

● httpd.service - The Apache HTTP Server
  Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
 Drop-In: /etc/systemd/system/httpd.service.d
          └─limits.conf
  Active: active (running) since Sat 2018-10-27 07:33:18 EDT; 3 days ago
 Process: 23826 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
 Process: 1462 ExecStartPre=/usr/sbin/httpd-fix-semaphore.sh (code=exited, status=0/SUCCESS)
 Main PID: 1503 (httpd)
  Status: "Total requests: 561930; Idle/Busy workers 100/0;Requests/sec: 1.83; Bytes served/sec: 3.9KB/sec"
  Memory: 381.2M
  CGroup: /system.slice/httpd.service
          ├─ 1503 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─ 2483 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─ 2582 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─ 2667 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─16683 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─20849 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─20947 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─23829 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/tmpdomain-error-%Y-%m-%d.log 86400
          ├─23830 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/error-ssl-%Y-%m-%d.log 86400
          ├─23831 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/error-%Y-%m-%d.log 86400
          ├─23832 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/tmpdomain-transfer-%Y-%m-%d.log 86400
          ├─23833 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/tmpdomain-transfer-%Y-%m-%d.log 86400
          ├─23834 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/transfer-ssl-%Y-%m-%d.log 86400
          ├─23835 /usr/sbin/rotatelogs -l -f /home/a1b4417e/var/briansnelson.com/logs/transfer-%Y-%m-%d.log 86400
          ├─23836 /usr/sbin/httpd -DSSL -DFOREGROUND
          ├─23837 /usr/sbin/fcgi- -DSSL -DFOREGROUND
          └─23844 /usr/sbin/httpd -DSSL -DFOREGROUND

This gives you a nice overview of the current status of the application, notifying you of any problems and any actions that may be required.

There are also methods for checking for specific states. For instance, to check to see if a unit is currently active (running), you can use the is-active command:

systemctl is-active application.service

This will return the current unit state, which is usually active or inactive. The exit code will be "0" if it is active, making the result simpler to parse programmatically.

To see if the unit is enabled, you can use the is-enabled command:

systemctl is-enabled application.service

This will output whether the service is enabled or disabled and will again set the exit code to "0" or "1" depending on the answer to the command question.

A third check is whether the unit is in a failed state. This indicates that there was a problem starting the unit in question:

systemctl is-failed application.service

This will return active if it is running properly or failed if an error occurred. If the unit was intentionally stopped, it may return unknown or inactive. An exit status of "0" indicates that a failure occurred and an exit status of "1" indicates any other status.

To see a list of all of the active units that systemd knows about, we can use the list-units command:

systemctl list-units

End

While systemctl operates mainly with the core systemd process, there are other components to the systemd ecosystem that are controlled by other utilities. Other capabilities, like log management and user sessions are handled by separate daemons and management utilities (journald/journalctl and logind/loginctl respectively). Taking time to become familiar with these other tools and daemons will make management an easier task.