1. Introduction

The core functions of Linux devices depend largely on the smooth running of services. These services often start at boot, ensuring that essential functions remain operational. Linux services are like silent workers that handle various tasks in the background to keep a system running smoothly.

In this tutorial, we’ll examine the functions of services, identify the services necessary for boot-up, and explore different methods to list all Linux services that start at boot.

For brevity and conciseness, we only work with services as defined by the initialization manager. However, not all processes are listed this way. For example, cron jobs and startup scripts can be checked, but they don’t necessarily handle services.

2. Linux Services

To begin with, let’s examine what we mean when we use the word services. Linux services are programs that run in the background and perform tasks essential for the smooth operation of a Linux device. Examples of such tasks include network connectivity, filesystem management, and process control.

In particular, services handle critical tasks such as managing network connections, initiating database servers, and implementing security measures like firewalls.

While some services are critical to operations, others don’t play significant roles for core functionality. Some potentially critical services include cron (task scheduling), ntpd (Network Time Protocol daemon), iptables (firewall), and others. On the other hand, non-critical services usually include vsftpd (FTP) and cups (printer service).

At this point, we have a basic understanding of services and their role in the seamless operation of Linux.

3. systemctl Command

systemctl is a command-line tool for controlling the Linux SystemD service manager. This utility contains numerous options to manipulate the different states of a service, list and manage services, and perform other administrative functions.

3.1. Basic Listing

First, let’s check the output of systemctl without any arguments:

$ systemctl
UNIT                                LOAD   ACTIVE     SUB       DESCRIPTION
proc-sys-fs-binfmt_misc.automount   loaded active     running   Arbitrary Executable File Formats File System Automount Point
dev-loop0.device                    loaded activating tentative /dev/loop0
dev-loop1.device                    loaded activating tentative /dev/loop1

The result above includes five columns:

  • Unit: enumerates the unit files which serves as a configuration document outlining how systemd should manage services, sockets, devices, or other system components
  • Load: indicates whether the unit file has been loaded by acknowledging its presence and configuration
  • Active: reflects the present state of the unit, indicating whether it’s currently active (running), inactive (not running), or in another phase
  • Sub: highlights the sub-state of the unit, detailing actions such as service initiation, termination, or error occurrences
  • Description: describes the unit, explaining its role or function within the system

In summary, this basic run of systemctl provides basic data about the services present and registered on the Linux system.

3.2. Filtering

After getting to know the basic usage of systemctl, let’s dive deeper and request a specific list of unit files based on a predefined filter:

$ systemctl list-unit-files --type=service
UNIT FILE                              STATE           VENDOR PRESET
apparmor.service                       enabled         enabled      
[email protected]                static          -            
apport.service                         generated       -            
[email protected]                        alias           -            
blk-availability.service               enabled         enabled      
chrony.service                         enabled         enabled      
chronyd.service                        alias           -            
cloud-config.service                   enabled         enabled      
console-getty.service                  disabled        disabled

In the output, we can identify which services start at boot. Notably, it is also important to understand the other information present in the result:

  • Unit File: lists the names of the service unit files
  • Vendor Preset: describes the default settings of the service unit file determined by the vendor
  • State: indicates the state of each service unit file

There are several states that a service can be in:

  • enabled: the service launches automatically during system startup
  • static: the service remains unchanged and cannot be toggled on or off by the user
  • generated: a program or script dynamically creates the service
  • alias: the service is a reference to another service unit file
  • disabled: the service is inactive and won’t start automatically during system startup

Considering the states above, we can deduce which services that are configured to start at boot, actually will.

4. Listing Linux Services Using services Command

The service command is a useful utility for managing services in Linux. While its main purpose revolves around initiating, halting, and administering services, it also enables users and administrators to display a list of services configured to start during system boot.

Unlike the systemctl command, service works on older systems with SystemV initialization.

To see what services are configured to start at boot on a Linux device, we can include the –status-all flag:

$ services --status-all
[+]  apparmor
[+]  apport
[+]  chrony
[-]  console-setup.sh
[+]  cron
[-]  cryptdisks
[-]  cryptdisks-early
[+]  dbus
[-]  grub-common
[-]  hwclock.sh
[+]  irqbalance'

The above command lists services and their status. Services marked with a positive sign (+) are configured to start at boot, whereas those with a dash () usually don’t start at boot.

5. Conclusion

In this article, we explored what services are all about and how crucial they are for the seamless operation of a device.

First, we checked two tools to list services that start at boot. After getting to know the systemctl command and its detailed view of service unit files and their states, we turned to the service command.