Oracle Cloud Infrastructure Documentation

Managing the System With systemd

Explains the role of systemd in Oracle Linux and how its configuration and units shape system startup.

systemd is the system initialization and service manager in Oracle Linux.

The systemd daemon is the first process that starts after a system boots and is the final process that's 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.

Tip

See Use Systemd on Oracle Linux for a hands-on tutorial and video demonstrations on working with systemd in Oracle Linux.

For more information about system boot, see Managing Kernels and System Boot on Oracle Linux.

systemd Configuration

systemd reads its configuration from files in the following directories, in order of priority:

  • $HOME/.config/systemd/: User specific systemd configuration entries.

  • /etc/systemd/: System-wide systemd configuration customization.

  • /run/systemd/: Runtime systemd configuration.

  • /usr/lib/systemd: Base systemd configuration provided by packages.

systemd configuration customization is stored in the /etc/systemd directory. For example, you could copy the /usr/lib/systemd/system.conf to /etc/systemd/system.conf file and edit it to control how systemd handles system initialization.

The systemd daemon starts services during the boot process by reading the symbolic link /etc/systemd/system/default.target.

The following example shows the value of /etc/systemd/system/default.target on a system configured to boot to a multiuser mode without a graphical user interface, a target called multi-user.target:

sudo ls -l /etc/systemd/system/default.target
 /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target
Note

You can use a kernel boot parameter to override the default system target. See Changing Kernel Boot Parameters Before Booting and Using grubby to Manage Kernels.

systemd Units

Overviews the major systemd unit types, how to list them, and where their configuration files live.

systemd organizes the different types of resources it manages into units.

Most units are configured in unit configuration files that enable you to configure these units according to system needs. In addition to the files, you can also use systemd runtime commands to configure the units.

To display all the types of units available in systemd, use the following command:

sudo systemctl -t help
Available unit types:
service
mount
swap
socket
target
device
automount
timer
path
slice
scope

The following list describes some system units that you can manage on an Oracle Linux system by using systemd:

Services
Service unit configuration files have the file name format service_name.service, for example sshd.service, crond.service, and httpd.service.

Service units start and control daemons and the processes of which the daemons consist.

The following example shows how you might start the systemd service unit for the Apache HTTP server, httpd.service: 

sudo systemctl start httpd.service

See Service Management in Systemd for more information.

Targets
Target unit configuration files have the file name format target_name.target, for example graphical.target.

Targets are similar to runlevels. A system reaches different targets during the boot process as resources get configured. For example, a system reaches network-pre.target before it reaches the target network-online.target.

Many target units have dependencies. For example, the activation of graphical.target (for a graphical session) fails unless multi-user.target (for multiuser system) is also active.

See Systemd Targets for more information.

File System Mount Points
Mount unit configuration files have the file name format mount_point_name.mount.
Mount units enable you to mount file systems at boot time. For example, you can run the following command to mount the temporary file system (tmpfs) on /tmp at boot time: 
sudo systemctl enable tmp.mount
Devices
Device unit configuration files have the file name format device_unit_name.device.

Device units are named after the /sys and /dev paths they control. For example, the device /dev/sda5 is exposed in systemd as dev-sda5.device.

Device units enable you to implement device-based activation.

Sockets
Socket unit configuration files have the file name format socket_unit_name.socket.

Each "*.socket" file needs a corresponding "*.service" file to configure the service to start on incoming traffic on the socket.

Socket units enable you to implement socket-based activation.

Timers

Timer unit configuration files have the file name format timer_unit_name.timer.

Each "*.timer" file needs a corresponding "*.service" file to configure the service to start at a configured timer event. A Unit configuration entry can be used to specify a service that's named differently to the timer unit, if required.

Timer units can control when service units are run and can act as an alternative to using the cron daemon. Timer units can be configured for calendar time events, monotonic time events, and can be run asynchronously.

See Working with Timers in Systemd for more information.

Paths to systemd unit configuration files vary depending on their purpose and whether systemd is running in 'user' or 'system' mode.

For example, configuration for units that are installed from packages might be available in /usr/lib/systemd/system or in /usr/local/lib/systemd/system, while a user mode configuration unit is likely to be stored in $HOME/.config/systemd/user. See the systemd.unit(5) manual page for more information.