Chapter 2 Working With System Services

This chapter describes how to manage system processes, services, and resources on a running Oracle Linux system. Information about how to change the systemd target for a system, as well as how to configure the services that are available for a target is also provided.

2.1 About the systemd Service Manager

The system and service manager that is used in Oracle Linux is systemd. The systemd process is the first process that starts after a system boots and is the final process that is running when the system shuts down. systemd controls the final stages of booting and prepares the system for use. It also speeds up booting by loading services concurrently.

systemd enables you to manage the following types of units on a system:

  • services (name.service)

  • targets (

  • devices (name.device)

  • file system mount points (name.mount)

  • sockets (name.socket)

For example, running the following command instructs the system to mount the temporary file system (tmpfs) on /tmp at boot time:

sudo systemctl enable tmp.mount

systemd reads its configuration from files in the /etc/systemd directory. For example, the /etc/systemd/system.conf file controls how systemd handles system initialization.

To determine which services to start systemd reads /etc/systemd/system/, which is a linked file to some other target file such as /usr/lib/systemd/system/


You can use a kernel boot parameter to override the default system target. See Section 1.3, “Kernel Boot Parameters”.

systemd brings the system to the state defined by the system target by performing system initialization tasks such as setting the host name, initializing the network, mounting file systems, and so on.

See Section 2.2, “About System-State Targets”.

2.2 About System-State Targets

Through system-state targets, you can control systemd so that it starts only the services that are required for a specific purpose. A server, for instance, can run more efficiently with because it does not run the X Window System at that run level. In another case, is best for performing diagnostics, backups, and upgrades when only root can use the system.

Each run level defines the services that systemd stops or starts. As an example, systemd starts network services for and the X Window System for, and stops both services for

Table 2.1, “System-State Targets and Equivalent Runlevel Targets” shows the commonly used system-state targets and the equivalent runlevel targets.

Table 2.1 System-State Targets and Equivalent Runlevel Targets

System-State Targets

Equivalent Runlevel Targets


Set up a multi-user system with networking and display manager.

Set up a non-graphical multi-user system with networking.

Shut down and power off the system.

Shut down and reboot the system.

Set up a rescue shell.

Note that runlevel* targets are implemented as symbolic links.

For more information, see the manual page.

2.2.1 Displaying Default and Active System-State Targets

To display the default system-state target, use the systemctl get-default command:

sudo systemctl get-default

To display the currently active targets on a system, use the systemctl list-units --type target command:

sudo systemctl list-units --type target [--all]
UNIT                   LOAD   ACTIVE SUB    DESCRIPTION                  loaded active active Basic System            loaded active active Local Encrypted Volumes           loaded active active Login Prompts            loaded active active Graphical Interface    loaded active active Local File Systems (Pre)        loaded active active Local File Systems      loaded active active Multi-User System   loaded active active Network is Online      loaded active active Network (Pre)              loaded active active Network                 loaded active active NFS client services loaded active active User and Group Name Lookups           loaded active active Paths                loaded active active Remote File Systems (Pre)       loaded active active Remote File Systems      loaded active active          loaded active active RPC Port Mapper             loaded active active Slices                     loaded active active Sockets                      loaded active active Sound Card             loaded active active            loaded active active Swap                       loaded active active System Initialization          loaded active active Timers                     

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.

24 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

The output for a system with the graphical target active shows that this target depends on a number of other active targets, including network and sound to support networking and sound.

Use the --all option to include inactive targets in the displayed list.

For more information, see the systemctl(1) and manual pages.

2.2.2 Changing Default and Active System-State Targets

Use the systemctl set-default command to change the default system-state target:

sudo systemctl set-default
Removed /etc/systemd/system/
Created symlink /etc/systemd/system/ → /usr/lib/systemd/system/

This command changes the target to which the default target is linked, but does not change the state of the system.

To change the currently active system target, use the systemctl isolate command, for example:

sudo systemctl isolate

For more information, see the systemctl(1) manual page.

2.3 Modifying systemd Configuration Files

To change the configuration of systemd services, copy all of the files with .service, .target, .mount and .socket extensions from /usr/lib/systemd/system to /etc/systemd/system.

The copies of the files in /etc/systemd/system take precedence over the version in /usr/lib/systemd/system, and are not overwritten when you update a package that touches files in /usr/lib/systemd/system.

To revert to the default systemd configuration for a particular service, either rename or delete the modified copies in /etc/systemd/system.

2.4 Shutting Down, Suspending, and Rebooting the System

Table 2.2 systemctl Commands for Shutting Down, Suspending, and Rebooting a System

systemctl Command


systemctl halt

Halt the system.

systemctl hibernate

Put the system into hibernation.

systemctl hybrid-sleep

Put the system into hibernation and suspend its operation.

systemctl poweroff

Halt and power off the system.

systemctl reboot

Reboot the system.

systemctl suspend

Suspend the system.

For more information, see the systemctl(1) manual page.

2.5 Managing Services

Services in an Oracle Linux system are managed by the systemctl subcommand command.

2.5.1 Starting and Stopping Services

To start a service, use the systemctl start command:

sudo systemctl start sshd

To stop a service, use the systemctl stop command:

sudo systemctl stop sshd

Changing the state of a service only lasts as long as the system remains at the same state. If you stop a service and then change the system-state target to one in which the service is configured to run (for example, by rebooting the system), the service restarts. Similarly, starting a service does not enable the service to start following a reboot. See Section 2.5.2, “Enabling and Disabling Services”.

systemctl supports the disable, enable, reload, restart, start, status, and stop actions for services. For other actions, you must either run the script that the service provides to support these actions, or for legacy scripts, the /etc/init.d script with the required action argument. For legacy scripts, omitting the argument to the script displays a usage message, for example:

For more information, see the systemctl(1) manual page.

2.5.2 Enabling and Disabling Services

You can use the systemctl command to enable or disable a service from starting when the system starts, for example:

sudo systemctl enable httpd
Created symlink /etc/systemd/system/ → 

The command enables a service by creating a symbolic link for the lowest-level system-state target at which the service should start. In the example, the command creates the symbolic link httpd.service for the multi-user target.

Disabling a service removes the symbolic link:

sudo systemctl disable httpd
Removed /etc/systemd/system/

To check whether a service is enabled, use is-enabled subcommand:

sudo systemctl is-enabled httpd
sudo systemctl is-enabled sshd

After running the systemctl disable command, the service can still be started or stopped by user accounts, scripts and other processes. If that is not your desired behavior, use the systemctl mask command to disable the service completely:

sudo systemctl mask httpd
Created symlink from '/etc/systemd/system/' to '/dev/null'

If you try to run the service, you will see an error message stating that the unit has been masked because the service reference was changed to /dev/null:

sudo systemctl start httpd
Failed to start httpd.service: Unit is masked.

To re-link the service reference back to the matching service unit configuration file, use the systemctl unmask command:

sudo systemctl unmask httpd

For more information, see the systemctl(1) manual page.

2.5.3 Displaying the Status of Services

To check whether a service is running, use the is-active subcommand. The output would either be active) or inactive, as shown in the following example:

sudo systemctl is-active httpd
systemctl is-active sshd

The status subcommand provides a detailed summary of the status of a service, including a tree that displays all of the tasks in the control group (cgroup) that the service implements:

sudo systemctl status httpd
  httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since ...
     Docs: man:httpd.service(8)
 Main PID: 11832 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 26213)
   Memory: 32.5M
   CGroup: /system.slice/httpd.service
           ├─11832 /usr/sbin/httpd -DFOREGROUND
           ├─11833 /usr/sbin/httpd -DFOREGROUND
           ├─11834 /usr/sbin/httpd -DFOREGROUND
           ├─11835 /usr/sbin/httpd -DFOREGROUND
           └─11836 /usr/sbin/httpd -DFOREGROUND

Jul 17 00:14:32 Unknown systemd[1]: Starting The Apache HTTP Server...
Jul 17 00:14:32 Unknown httpd[11832]: Server configured, listening on: port 80
Jul 17 00:14:32 Unknown systemd[1]: Started The Apache HTTP Server.

A cgroup is a collection of processes that are bound together so that you can control their access to system resources. In the example, the cgroup for the httpd service is httpd.service, which is in the system slice.

Slices divide the cgroups on a system into different categories. To display the slice and cgroup hierarchy, use the systemd-cgls command:

sudo systemd-cgls
Control group /:
│ └─user-1000.slice
│   ├─user@1000.service
│   │ └─init.scope
│   │   ├─6488 /usr/lib/systemd/systemd --user
│   │   └─6492 (sd-pam)
│   └─session-7.scope
│     ├─6484 sshd: root [priv]
│     ├─6498 sshd: root@pts/0
│     ├─6499 -bash
│     ├─6524 sudo systemd-cgls
│     ├─6526 systemd-cgls
│     └─6527 less
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 16
  │ └─1266 /sbin/rngd -f --fill-watermark=0
  │ └─1247 /usr/sbin/irqbalance --foreground
  │ └─1201 /usr/bin/lsmd -d
  │ └─1060 /usr/lib/systemd/systemd-udevd
  │ └─1241 /usr/lib/polkit-1/polkitd --no-debug
  │ └─1249 /usr/sbin/chronyd
  │ ├─1152 /sbin/auditd
  │ └─1154 /usr/sbin/sedispatch
  │ └─1382 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
  │ └─1027 /usr/lib/systemd/systemd-journald
  │ └─1812 /usr/sbin/atd -f
  │ └─1781 /usr/sbin/sshd

The system.slice contains services and other system processes. user.slice contains user processes, which run within transient cgroups called scopes. In the example, the processes for the user with ID 1000 are running in the scope session-7.scope under the slice /user.slice/user-1000.slice.

You can use the systemctl command to limit the CPU, I/O, memory, and other resources that are available to the processes in service and scope cgroups. See Section 2.5.4, “Controlling Access to System Resources”.

For more information, see the systemctl(1) and systemd-cgls(1) manual pages.

2.5.4 Controlling Access to System Resources

Use the systemctl command to control a cgroup's access to system resources, for example:

sudo systemctl [--runtime] set-property httpd CPUShares=512 MemoryLimit=1G

CPUShare controls access to CPU resources. As the default value is 1024, a value of 512 halves the access that the processes in the cgroup have to CPU time. Similarly, MemoryLimit controls the maximum amount of memory that the cgroup can use.


You do not need to specify the .service extension to the name of a service.

If you specify the --runtime option, the setting does not persist across system reboots.

Alternatively, you can change the resource settings for a service under the [Service] heading in the service's configuration file in /usr/lib/systemd/system. After editing the file, make systemd reload its configuration files and then restart the service:

sudo systemctl daemon-reload
sudo systemctl restart service

You can run general commands within scopes and use systemctl to control the access that these transient cgroups have to system resources. To run a command within in a scope, use the systemd-run command:

sudo systemd-run --scope --unit=group_name [--slice=slice_name]

If you do not want to create the group under the default system slice, you can specify another slice or the name of a new slice. The following example runs a command named mymonitor in mymon.scope under myslice.slice:

sudo systemd-run --scope --unit=mymon --slice=myslice mymonitor
Running as unit mymon.scope.

If you do not specify the --scope option, the control group is a created as a service rather than as a scope.

You can then use systemctl to control the access that a scope has to system resources in the same way as for a service. However, unlike a service, you must specify the .scope extension, for example:

sudo systemctl --runtime set-property mymon.scope CPUShares=256

For more information see the systemctl(1), systemd-cgls(1), and systemd.resource-control(5) manual pages.

2.5.5 Running systemctl on a Remote System

If the sshd service is running on a remote Oracle Linux system, specify the -H option with the systemctl command to control the system remotely, for example:

sudo systemctl -H root@ status sshd
root@'s password: password
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since ...
  Process: 1498 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
 Main PID: 1524 (sshd)
   CGroup: /system.slice/sshd.service

For more information see the systemctl(1) manual page.

2.6 Creating User Based Services

Systemd enables you to create services that you can then run from a user level without requiring root access and privileges. These user based services are under your control and are configurable independent of system services.

The feature is particularly useful when creating podman container services. For more information about podman, see Oracle® Linux: Podman User's Guide.

2.6.1 About Service Unit Files

Services run based on their corresponding service unit files. A unit file typically contains the following sections, with each section having its respective defined options that determine how a specific service runs:

  • [Unit]: Contains information about the service.

  • [Unit Type]: Identifies the type of systemd unit file. Services, for example, use the service type. Other types of unit files are target, device, mount, and so on. For a list of unit types, see the systemd.unit(5) manual page.

  • [Install]: Contains installation information for the specific unit. The information in this section is used by the systemctl enable and systemctl disable commands.

A service unit file might contain the following configurations for a service.

Description=Service description

ExecStart=script path


The options under each section are explained as follows:


Provides information about the service. The information is displayed when you run the systemctl status command on the service.


Identifies the main process of the service. By default, this parameter's value is simple, which indicates that the service's main process is that which is started by the ExecStart parameter. Typically, if a service's type is simple, then the definition can be omitted from the file.


Identifies how you log the service's events. In the example, journal indicates that the system log is used, which can be viewed by using the journalctl command.


Specifies the full path and command that starts the service, for example, /usr/bin/npm start.


Identifies other units that will have a dependency relationship with this specific unit file. Those units are typically listed in the file called To view the contents of this file, run the systemctl get-default command.

For additional options you can use, see Section 2.6.3, “Configurable Options in Service Unit Files”. A complete list is also available in the systemd.service(5) and systemd.unit(5) manual pages.

2.6.2 Creating a Systemd User Based Service

The following are basic steps to create a user based service:

  1. Create your service's unit file in the ~/.config/systemd/user directory, for example:

    touch ~/.config/systemd/user/myservice.service
  2. Open the unit file and specify the values to the options you want to use, such as Description, ExecStart, WantedBy, and so on.

    For reference, see Section 2.6.3, “Configurable Options in Service Unit Files” and the systemd.service(5) and systemd.unit(5) manual pages.

  3. Enable the service to start automatically when you log in.

    sudo systemctl --user enable myservice.service

    When you log out, the service is generally stopped unless the root user has enabled processes to continue to run for your user. See for more information.

  4. Start the service.

    sudo systemctl --user start myservice.service
  5. Verify that the service is running.

    sudo systemctl --user status myservice.service

2.6.3 Configurable Options in Service Unit Files

The following table shows the sections of a service unit file and their corresponding options that you can configure.

[Unit] [Service] [Install]



















For details about these options, see the systemd.service(5) and systemd.unit(5) manual pages.