20200828

How to view status of a service on Linux using systemctl

 How to view status of a service on Linux using systemctl

How do I use the systemctl command to view status of a systemd service on Linux operating systems?

We use systemctl status command under systemd to view the status of the given service on Linux operating systems.

Viewing the Status of a Service

The syntax is as follows for the systemctl commandsystemctl status {service-name}
systemctl status {unit-name}

How to view status of a service called nginx

Type:
$ systemctl status nginx.service
## ssh server status ##
$ systemctl status sshd.service
## Lighttpd web server status ##
$ systemctl status lighttpd.service

 lighttpd.service - Lighttpd Daemon
     Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2020-08-04 04:29:19 UTC; 3 weeks 2 days ago
   Main PID: 105 (lighttpd)
      Tasks: 1 (limit: 115783)
     Memory: 56.5M
     CGroup: /system.slice/lighttpd.service
             └─105 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

Aug 04 04:29:19 utls-bash-wiki systemd[1]: Starting Lighttpd Daemon...
Aug 04 04:29:19 utls-bash-wiki systemd[1]: Started Lighttpd Daemon.

The syntax is as follows for the systemctl commandsystemctl status {service-name}
systemctl status {unit-name}

How to view status of a service called nginx

Type:
$ systemctl status nginx.service
## ssh server status ##
$ systemctl status sshd.service
## Lighttpd web server status ##
$ systemctl status lighttpd.service

lighttpd.service - Lighttpd Daemon Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-08-04 04:29:19 UTC; 3 weeks 2 days ago Main PID: 105 (lighttpd) Tasks: 1 (limit: 115783) Memory: 56.5M CGroup: /system.slice/lighttpd.service └─105 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Aug 04 04:29:19 utls-bash-wiki systemd[1]: Starting Lighttpd Daemon... Aug 04 04:29:19 utls-bash-wiki systemd[1]: Started Lighttpd Daemon.

The dot (““) uses color on supported terminals to summarize the unit state at a glance. White color indicates an “inactive” or “deactivating” state. Red color indicates a “failed” or “error” state. Green indicates an “active”, “reloading” or “activating” state.

Understanding systemd service/unit states

The status of Linux service depends upon various states such as follows:

Service statusDescription
active (running)Service or daemon is running in the background. For example, sshd or nginx/apache web server and listing for incoming traffic.
active (exited)Service successfully started from the config file. Typically one time services configuration read before Service was exited. For example, AppArmor or Firewall service.
active (waiting)Our service is running but waiting for an event such as CPUS/printing event.
inactiveService is not running.
enabledService is enabled at boot time.
disabledService is disbled and will not be started at Linux server boot time.
staticService cannot be enabled on Linux, but mostly started by another systemd unit automatically. In other words, the unit file is not enabled and has no provisions for allowing in the [Install] unit file section.
maskedService is completely disabled and any start operation on it always fails.
aliasService name is an alias. It means service is symlink to another unit file.
linkedMade available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path.

Currently following units are supported by systemd

  • service : Service unit configuration about a process controlled and supervised by systemd.
  • mount : File system mount point controlled and supervised by systemd.
  • swap : Swap file/disk configuration controlled by systemd.
  • socket : An IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.
  • target : It contains information about a target unit of systemd. It is used for grouping units and as well-known synchronization points during start-up. For example, graphical.target is used for GUI based desktop login. Similarly, multi-user.target is used by servers where users can log in using ssh/console.
  • device : A device unit as exposed in the sysfs/udev device tree. It includes networking and other devices.
  • automount : Automount file systems
  • timer : Cron like systemd unit to run commands and services at a given date/time format. For example, refresh firmware or clean session created by Python or PHP webapps.
  • path : A systemd special target unit that sets up all path units. For example, systemd can take certian action depend upon file system path. If /etc/foo/ modifed take some action.
  • slice : We use a systemd slice for isolating workloads. They define a hierarchy in which scopes and service is placed. The actual processes are contained in scopes or in services. Think it as lightweight Docker. For each slice, certain resource limits such as CPU or disk I/O limit may be set that apply to all processes.
  • scope : Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. They are named similar to filenames. A unit whose name ends in “.scope” refers to a scope unit. Scopes units manage a set of system processes. Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.

We can list all services unit as follows:
$ sudo systemctl --type=service
Want to see mount type units? Try:
$ sudo systemctl --type=mount
Display all systemd timer units on your Linux box:
$ sudo systemctl -t timer

UNIT LOAD ACTIVE SUB DESCRIPTION ____________________________________________________________________________________________________________ anacron.timer loaded active waiting Trigger anacron every hour apt-daily-upgrade.timer loaded active waiting Daily apt upgrade and clean activities apt-daily.timer loaded active waiting Daily apt download activities e2scrub_all.timer loaded active waiting Periodic ext4 Online Metadata Check for All Filesystems fstrim.timer loaded active waiting Discard unused blocks once a week fwupd-refresh.timer loaded active waiting Refresh fwupd metadata regularly logrotate.timer loaded active waiting Daily rotation of log files man-db.timer loaded active waiting Daily man-db regeneration mdcheck_start.timer loaded active waiting MD array scrubbing mdmonitor-oneshot.timer loaded active waiting Reminder for degraded MD arrays motd-news.timer loaded active waiting Message of the Day phpsessionclean.timer loaded active waiting Clean PHP session files every 30 mins systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 13 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use:

$ sudo systemctl list-unit-files
Linux Listing Unit Files with Systemctl Command

Linux view status of a service

Type the following command to view all services and unit status on your Linux system since boot time:
$ sudo systemctl

Linux see state of all units to verify a system startup

Click to enlarge

Use the grep command/egrep command to filter out required units/services:
$ sudo systemctl | grep ssh
$ sudo systemctl | egrep 'apache|nginx|lighttpd|php'

How to view status of a service on Linux using systemctl

How to list units that systemd currently has in memory

Execute the following command:
$ sudo systemctl list-units
$ sudo systemctl list-units | more
$ sudo systemctl list-units | grep sshd
## filter by unit types ##
$ sudo systemctl list-units --type service
$ sudo systemctl list-units --type timer

List systemd/systemctl all failed units/services on Linux

$ sudo systemctl list-units --failed
$ sudo systemctl list-units --state failed
## filtering by unit type ##
$ sudo systemctl list-units --state failed --type service
$ sudo systemctl list-units --state failed --type timer

Linux systemctl list all failed units or services command

The systemctl command to list all failed units or services

The dot (““) uses color on supported terminals to summarize the unit state at a glance. White color indicates an “inactive” or “deactivating” state. Red color indicates a “failed” or “error” state. Green indicates an “active”, “reloading” or “activating” state.

Understanding systemd service/unit states

The status of Linux service depends upon various states such as follows:

Service statusDescription
active (running)Service or daemon is running in the background. For example, sshd or nginx/apache web server and listing for incoming traffic.
active (exited)Service successfully started from the config file. Typically one time services configuration read before Service was exited. For example, AppArmor or Firewall service.
active (waiting)Our service is running but waiting for an event such as CPUS/printing event.
inactiveService is not running.
enabledService is enabled at boot time.
disabledService is disbled and will not be started at Linux server boot time.
staticService cannot be enabled on Linux, but mostly started by another systemd unit automatically. In other words, the unit file is not enabled and has no provisions for allowing in the [Install] unit file section.
maskedService is completely disabled and any start operation on it always fails.
aliasService name is an alias. It means service is symlink to another unit file.
linkedMade available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path.

Currently following units are supported by systemd

  • service : Service unit configuration about a process controlled and supervised by systemd.
  • mount : File system mount point controlled and supervised by systemd.
  • swap : Swap file/disk configuration controlled by systemd.
  • socket : An IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.
  • target : It contains information about a target unit of systemd. It is used for grouping units and as well-known synchronization points during start-up. For example, graphical.target is used for GUI based desktop login. Similarly, multi-user.target is used by servers where users can log in using ssh/console.
  • device : A device unit as exposed in the sysfs/udev device tree. It includes networking and other devices.
  • automount : Automount file systems
  • timer : Cron like systemd unit to run commands and services at a given date/time format. For example, refresh firmware or clean session created by Python or PHP webapps.
  • path : A systemd special target unit that sets up all path units. For example, systemd can take certian action depend upon file system path. If /etc/foo/ modifed take some action.
  • slice : We use a systemd slice for isolating workloads. They define a hierarchy in which scopes and service is placed. The actual processes are contained in scopes or in services. Think it as lightweight Docker. For each slice, certain resource limits such as CPU or disk I/O limit may be set that apply to all processes.
  • scope : Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. They are named similar to filenames. A unit whose name ends in “.scope” refers to a scope unit. Scopes units manage a set of system processes. Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.

We can list all services unit as follows:
$ sudo systemctl --type=service
Want to see mount type units? Try:
$ sudo systemctl --type=mount
Display all systemd timer units on your Linux box:
$ sudo systemctl -t timer

  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION     
____________________________________________________________________________________________________________                                       
  anacron.timer                loaded active waiting Trigger anacron every hour                             
  apt-daily-upgrade.timer      loaded active waiting Daily apt upgrade and clean activities                 
  apt-daily.timer              loaded active waiting Daily apt download activities                          
  e2scrub_all.timer            loaded active waiting Periodic ext4 Online Metadata Check for All Filesystems
  fstrim.timer                 loaded active waiting Discard unused blocks once a week                      
  fwupd-refresh.timer          loaded active waiting Refresh fwupd metadata regularly                       
  logrotate.timer              loaded active waiting Daily rotation of log files                            
  man-db.timer                 loaded active waiting Daily man-db regeneration                              
  mdcheck_start.timer          loaded active waiting MD array scrubbing                                     
  mdmonitor-oneshot.timer      loaded active waiting Reminder for degraded MD arrays                        
  motd-news.timer              loaded active waiting Message of the Day                                     
  phpsessionclean.timer        loaded active waiting Clean PHP session files every 30 mins                  
  systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

13 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use:

$ sudo systemctl list-unit-files
Linux Listing Unit Files with Systemctl Command

Linux view status of a service

Type the following command to view all services and unit status on your Linux system since boot time:
$ sudo systemctl

Linux see state of all units to verify a system startup

Click to enlarge

Use the grep command/egrep command to filter out required units/services:
$ sudo systemctl | grep ssh
$ sudo systemctl | egrep 'apache|nginx|lighttpd|php'

How to view status of a service on Linux using systemctl

How to list units that systemd currently has in memory

Execute the following command:
$ sudo systemctl list-units
$ sudo systemctl list-units | more
$ sudo systemctl list-units | grep sshd
## filter by unit types ##
$ sudo systemctl list-units --type service
$ sudo systemctl list-units --type timer

List systemd/systemctl all failed units/services on Linux

$ sudo systemctl list-units --failed
$ sudo systemctl list-units --state failed
## filtering by unit type ##
$ sudo systemctl list-units --state failed --type service
$ sudo systemctl list-units --state failed --type timer

Linux systemctl list all failed units or services command

The systemctl command options to list all failed units/services

  What to do if the service such as nginx is not running?

Turn on the systemd service:
$ sudo systemctl enable nginx.service
Start the nginx service:
$ sudo systemctl start nginx.service
We can stop or restart the service as follows:
$ sudo systemctl stop nginx.service
$ sudo systemctl restart nginx.service

Verify that if a service enabled or not, run:
$ sudo is-enabled nginx.service
See status again:
$ sudo status nginx.service
To see full outputs for debug service issue pass the --full or -l option:
$ sudo status nginx.service -l
$ sudo status openvpn.service --full

We can debug and see all log messages related to service using the journalctl command:
$ sudo journalctl UNIT=nginx.service

Aug 02 03:51:05 utls-wp-mg-www-cbz systemd[1]: Stopped A high performance web server and a reverse proxy server.
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 02 03:53:05 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:53:05 utls-wp-mg-www-cbz systemd[1]: Started A high performance web server and a reverse proxy server.
Aug 04 04:11:47 utls-wp-mg-www-cbz systemd[1]: Stopping A high performance web server and a reverse proxy server...
Aug 04 04:11:48 utls-wp-mg-www-cbz systemd[1]: nginx.service: Succeeded.
Aug 04 04:11:48 utls-wp-mg-www-cbz systemd[1]: Stopped A high performance web server and a reverse proxy server.
-- Reboot --
Aug 04 04:27:35 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 04 04:27:35 utls-wp-mg-www-cbz systemd[1]: Started A high performance web server and a reverse proxy server.

     How to view systemd service/unit file source

Pass the cat option as follows (it like cat command):
$ sudo systemctl cat {service-name}
$ sudo systemctl cat nginx.service

 /lib/systemd/system/nginx.service
# Stop dance for nginx
# =======================
#
# ExecStop sends SIGSTOP (graceful stop) to the nginx process.
# If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control
# and sends SIGTERM (fast shutdown) to the main process.
# After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends
# SIGKILL to all the remaining processes in the process group (KillMode=mixed).
#
# nginx signals reference doc:
# http://nginx.org/en/docs/control.html
#
[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target
 
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed
 
[Install]
WantedBy=multi-user.target

Conclusion

You learned about listing systemd units, including Linux services, with systemctl command. See systemctl documentation or type the following man command:
$ man systemctl
$ systemctl --help

No comments: