systemd(1)

systemd(1)

NAME

systemd, init — systemd system and service manager

SYNOPSIS

/usr/lib/systemd/systemd [OPTIONS...]

init [OPTIONS...]

DESCRIPTION

systemd is a system and service manager for Linux operating systems. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate instances are started for logged-in users to start their services.

systemd is usually not invoked directly by the user, but is installed as the /sbin/init symlink and started during early boot. The user manager instances are started automatically through the user@.service(5) service.

When run as a system instance, systemd interprets the configuration file system.conf and the files in system.conf.d directories; when run as a user instance, systemd interprets the configuration file user.conf and the files in user.conf.d directories. See systemd-system.conf(5) for more information.

systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the hostname or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys/, /proc/, and /dev/.

systemd will also reset the system clock during early boot if it appears to be set incorrectly. See the section System clock epoch below.

Note that some but not all interfaces provided by systemd are covered by the Interface Portability and Stability Promise.

The D-Bus API of systemd is described in org.freedesktop.systemd1(5) and org.freedesktop.LogControl1(5).

Systems which invoke systemd in a container or initrd environment should implement the Container Interface or initrd Interface specifications, respectively.

UNITS

systemd provides a dependency system between various entities called “units” of 11 different types. Units encapsulate various objects that are relevant for system boot-up and maintenance. The majority of units are configured in unit configuration files, whose syntax and basic set of options is described in systemd.unit(5), however some are created automatically from other configuration files, dynamically from system state or programmatically at runtime. Units may be in a number of states, described in the following table.

State	Description
active	Started, bound, plugged in, ..., depending on the unit type.
inactive	Stopped, unbound, unplugged, ..., depending on the unit type.
failed	Similar to inactive, but the unit failed in some way.
activating	Changing from inactive to active.
deactivating	Changing from active to inactive.
maintenance	Unit is inactive and a maintenance operation is in progress.
reloading	Unit is active and it is reloading its configuration.
refreshing	Unit is active and a new mount is being activated in its namespace.

The following unit types are available:

1. Service units, which start and control daemons and the processes they consist of. See systemd.service(5).
2. Socket units, which encapsulate local IPC or network sockets in the system, useful for socket-based activation. See systemd.socket(5) and daemon(7).
3. Target units, useful to group units or provide well-known synchronization points during boot-up. See systemd.target(5).
4. Device units, which expose kernel devices in systemd and may be used to implement device-based activation. See systemd.device(5).
5. 'Mount units, controlling mount points in the file system. See systemd.mount(5).
6. 'Automount units, providing automount capabilities. See systemd.automount(5).
7. 'Timer units, useful for triggering activation of other units based on timers. See systemd.timer(5).
8. 'Swap units, similar to mount units and encapsulating memory swap partitions or files. See systemd.swap(5).
9. 'Path units, which may be used to activate other services when file system objects change or are modified. See systemd.path(5).
10. 'Slice units, used to group units that manage system processes in a hierarchical tree for resource management. See systemd.slice(5).
11. 'Scope units, similar to service units, but managing foreign processes instead of starting them. See systemd.scope(5).

Units are named as their configuration files. Some units have special semantics. A detailed list is available in systemd.special(7).

systemd knows various kinds of dependencies, including positive and negative requirement dependencies (for example Requires= and Conflicts=) as well as ordering dependencies (After= and Before=). Ordering and requirement dependencies are orthogonal.

Application programs and units may request state changes of units. In systemd, these requests are encapsulated as “jobs” and maintained in a job queue. Jobs may succeed or fail, and their execution is ordered based on the ordering dependencies of the units.

On boot systemd activates the target unit default.target, whose job is to activate on-boot services and other on-boot units by pulling them in via dependencies. Usually, the unit name is just an alias (symlink) for either graphical.target or multi-user.target, but the administrator may configure it as an alias to any other target unit.

On first boot, systemd will enable or disable units according to preset policy. See systemd.preset(5) and “First Boot Semantics” in machine-id(5).

systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are kept loaded are those for which at least one of the following conditions is true:

1. It is in an active, activating, deactivating or failed state.
2. It has a job queued for it.
3. It is a dependency of at least one other loaded unit.
4. It has some form of resource still allocated.
5. It has been pinned into memory programmatically by a D-Bus call.

systemd will automatically and implicitly load units from disk as soon as operations are requested for them. Use systemctl list-units --all to comprehensively list all units currently loaded.

Processes systemd spawns are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy. See Control Groups v2 for more information.

systemd is compatible with various established Unix functionality such as /etc/fstab or the utmp database.

systemd has a minimal transaction system. Before executing a requested operation, systemd will verify that it makes sense, fixing it if possible, and only failing if it really cannot work.

Units may be generated dynamically at boot and system manager reload time, for example based on other configuration files or parameters passed on the kernel command line. For details, see systemd.generator(7).

DIRECTORIES

System unit directories

The systemd system manager reads unit configuration from various directories. Packages that want to install unit files shall place them in the directory returned by:

pkg-config systemd --variable=systemdsystemunitdir

Other directories checked are:

• /usr/local/lib/systemd/system
• /usr/lib/systemd/system

User configuration always takes precedence. The following command returns the path of the system configuration directory:

pkg-config systemd --variable=systemdsystemconfdir

Packages should alter the content of these directories only with the enable and disable commands of systemctl(1). Full list of directories is provided in systemd.unit(5).

User unit directories

Similar rules apply for user unit directories. Here the XDG Base Directory specification is followed to find units. Applications should place unit files in the directory returned by:

pkg-config systemd --variable=systemduserunitdir

Global configuration is done in the directory reported by:

pkg-config systemd --variable=systemduserconfdir

SIGNALS

The service listens to various UNIX process signals that can be used to request various actions asynchronously.

SIGTERM

System manager: serializes state, reexecutes itself, deserializes state again. Similar to systemctl daemon-reexec.

User manager: starts the exit.target unit.

SIGINT

System manager: starts the ctrl-alt-del.target unit. If received more than 7 times per 2s, an immediate reboot is triggered.

User manager: treated the same as SIGTERM.

SIGWINCH

System manager: starts the kbrequest.target unit.

User manager: ignored.

SIGPWR

Starts the sigpwr.target unit.

SIGUSR1

Reconnect to the D-Bus bus.

SIGUSR2

Log complete internal state in human-readable form.

SIGHUP

Reload complete daemon configuration. Similar to systemctl daemon-reload.

SIGRTMIN+0

Enter default mode, start default.target.

SIGRTMIN+1

Enter rescue mode, start rescue.target.

SIGRTMIN+2

Enter emergency mode, start emergency.service.

SIGRTMIN+3

Halt the machine, start halt.target.

SIGRTMIN+4

Power off the machine, start poweroff.target.

SIGRTMIN+5

Reboot the machine, start reboot.target.

SIGRTMIN+6

Reboot the machine via kexec, start kexec.target.

SIGRTMIN+7

Reboot userspace, start soft-reboot.target.

Added in version 254.

SIGRTMIN+13

Immediately halt the machine.

SIGRTMIN+14

Immediately power off the machine.

SIGRTMIN+15

Immediately reboot the machine.

SIGRTMIN+16

Immediately reboot the machine with kexec.

SIGRTMIN+17

Immediately reboot the userspace.

Added in version 254.

SIGRTMIN+20

Enable display of status messages on the console.

SIGRTMIN+21

Disable display of status messages on the console.

SIGRTMIN+22

Set log level to “debug”.

SIGRTMIN+23

Restore configured log level.

Added in version 239.

SIGRTMIN+24

Immediately exit the manager (only for --user instances).

Added in version 195.

SIGRTMIN+25

Reexecute the systemd manager asynchronously.

Added in version 250.

SIGRTMIN+26

Restore configured log target.

Added in version 239.

SIGRTMIN+27, SIGRTMIN+28

Set log target to “console” or “kmsg”.

Added in version 239.

ENVIRONMENT

The environment block for the system manager is initially set by the kernel. For the user manager, the system manager sets the environment as described in the “Environment Variables in Spawned Processes” section of systemd.exec(5).

Some of the variables understood by systemd:

$SYSTEMD_LOG_LEVEL

Maximum log level of emitted messages.

$SYSTEMD_LOG_COLOR

Boolean. If true, tty messages are colored according to priority.

$SYSTEMD_LOG_TIME

Boolean. If true, console log messages are prefixed with a timestamp.

Added in version 246.

$SYSTEMD_LOG_LOCATION

Boolean. If true, messages are prefixed with source filename and line number.

$SYSTEMD_LOG_TID

Boolean. If true, messages are prefixed with thread ID.

Added in version 247.

$SYSTEMD_LOG_TARGET

Destination for log messages. One of:

console, console-prefixed, kmsg, journal, journal-or-kmsg, auto, null.

$SYSTEMD_LOG_RATELIMIT_KMSG

Boolean. Whether to ratelimit messages written to kmsg.

Added in version 254.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS

Used by the user manager according to the XDG Base Directory specification.

$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH

Control where systemd looks for unit files and generators.

$SYSTEMD_PAGER, $PAGER

Pager to use when --no-pager is not given.

$SYSTEMD_LESS

Override options passed to less.

$SYSTEMD_LESSCHARSET

Override charset passed to less.

$SYSTEMD_PAGERSECURE

Boolean. Controls use of pager “secure mode”.

$SYSTEMD_COLORS

Boolean or one of “16”, “256”. Controls color usage.

$SYSTEMD_URLIFY

Boolean. Controls whether clickable links are generated.

$LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES

Set by systemd during socket-based activation. See sd_listen_fds(3).

$NOTIFY_SOCKET

Set for services for status and readiness notifications. See sd_notify(3).

For further environment variables understood by systemd and its various components, see Known Environment Variables.

KERNEL COMMAND LINE

When run as the system instance, systemd parses a number of options from the kernel command line.

The following variables are understood:

systemd.unit=, rd.systemd.unit=

Override the unit to activate on boot. Defaults to default.target.

systemd.dump_core

Boolean. If enabled, PID 1 dumps core when it crashes.

Added in version 233.

systemd.crash_chvt

Positive integer or boolean. Activate the specified virtual terminal when PID 1 crashes.

Added in version 233.

systemd.crash_shell

Boolean. If enabled, PID 1 spawns a shell when it crashes.

Added in version 233.

systemd.crash_action=

One of “freeze”, “reboot”, “poweroff”.

Added in version 256.

systemd.confirm_spawn

Boolean or console path. Ask for confirmation when spawning processes using /dev/console.

Added in version 233.

systemd.service_watchdogs=

Boolean. Enable or disable service runtime watchdogs and emergency actions.

Added in version 237.

systemd.show_status

Boolean or “error” or “auto”. Controls terse service status updates on the console.

Added in version 233.

systemd.status_unit_format=

One of name, description, combined.

Added in version 243.

systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=, systemd.log_time, systemd.log_tid, systemd.log_ratelimit_kmsg

Control log output.

systemd.default_standard_output=, systemd.default_standard_error=

Control default standard output and error output for services and sockets.

systemd.setenv=

Set default environment variables for child processes.

systemd.machine_id=

32-character hex value for machine ID.

Added in version 229.

systemd.set_credential=, systemd.set_credential_binary=

Set system credentials via kernel command line.

Added in version 251.

systemd.import_credentials=

Boolean. Disable importing credentials from supported firmware/boot mechanisms.

Added in version 251.

quiet

Turn off status output at boot.

debug

Turn on debugging output.

emergency, rd.emergency, -b

Boot into emergency mode.

rescue, rd.rescue, single, s, S, 1

Boot into rescue mode.

2, 3, 4, 5

Boot into corresponding legacy SysV runlevels.

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, ...

Set the system locale to use.

For other kernel command line parameters, see kernel-command-line(7).

SYSTEM CREDENTIALS

During initialization the service manager imports credentials from various sources into the system credential set, which can then be propagated into services and consumed by generators.

Sources include:

• SMBIOS Type 11 vendor strings
• QEMU fw_cfg
• Kernel command line via systemd.set-credential=
• UEFI environment via systemd-stub(7)
• Files in /run/credentials/@initrd/ during initrd → host transition

To inspect credentials:

# systemd-creds --system list

The service manager when run as PID 1 consumes the following system credentials:

vmm.notify_socket

Contains an AF_VSOCK or AF_UNIX address where to send a READY=1 notification.

Added in version 254.

system.machine_id

128-bit hexadecimal ID to initialize /etc/machine-id from.

Added in version 254.

For more, see systemd.system-credentials(7).

READINESS PROTOCOL

The service manager implements a readiness notification protocol both between the manager and its services and between the manager and a supervisor further up the stack. The basic protocol is described in sd_notify(3).

The notification protocol from the service manager upwards supports extension fields, including:

X_SYSTEMD_HOSTNAME=...

Sent once the initial hostname has been determined.

Added in version 256.

X_SYSTEMD_MACHINE_ID=...

Sent once the machine ID has been determined.

Added in version 256.

X_SYSTEMD_SIGNALS_LEVEL=...

Sent once signal handlers have been installed.

Added in version 256.

X_SYSTEMD_UNIT_ACTIVE=... and X_SYSTEMD_UNIT_INACTIVE=...

Sent for target units as they become active or inactive.

Added in version 256.

X_SYSTEMD_SHUTDOWN=...

Sent shortly before shutdown. Value is one of “reboot”, “halt”, “poweroff”, “kexec”.

Added in version 256.

X_SYSTEMD_REBOOT_PARAMETER=...

Sent shortly before shutdown with configured reboot argument.

Added in version 256.

These are sent in addition to the usual READY=1 and RELOADING=1 notifications.

OPTIONS

systemd is usually not invoked directly. The options below are mainly useful for debugging and special purposes.

Introspection and debugging options

--dump-configuration-items

Dump understood unit configuration items.

--dump-bus-properties

Dump exposed bus properties.

Added in version 239.

--test

Determine the initial start-up transaction, dump it, and exit without executing jobs.

--system, --user

Used with --test to select system or user instance.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

Options that duplicate kernel command line settings

--unit=

Set default unit to activate on startup.

--dump-core

Enable core dumping on crash.

'--crash-vt=VT

Switch to a specific virtual console on crash.

Added in version 227.

--crash-shell

Run a shell on crash.

'--crash-action=

Specify what to do when PID 1 crashes.

Added in version 256.

--confirm-spawn

Ask for confirmation when spawning processes.

--show-status

Show terse unit status information on the console during boot-up and shutdown.

Added in version 244.

--log-color

Highlight important log messages.

Added in version 244.

'--log-level=

Set log level.

--log-location

Include code location in log messages.

Added in version 244.

'--log-target=

Set log target.

--log-time

Prefix console messages with timestamp.

Added in version 246.

'--machine-id=

Override the machine-id set on the hard drive.

Added in version 229.

--service-watchdogs

Globally enable or disable all service watchdog timeouts and emergency actions.

Added in version 237.

--default-standard-output=, --default-standard-error=

Set default output/error output for all services and sockets.

SYSTEM CLOCK EPOCH

When systemd is started or restarted, it may set the system clock to the “epoch”. This mechanism ensures that the system clock remains reasonably initialized and roughly monotonic across reboots.

The epoch is the lowest date above which the system clock time is assumed to be set correctly. On initialization, the local clock is advanced to the epoch if it was set lower. If the local clock is sufficiently far in the future, the hardware clock is assumed broken and the system clock is rewound to the epoch.

The epoch is set to the highest of:

• the build time of systemd
• the modification time of /usr/lib/clock-epoch
• the modification time of /var/lib/systemd/timesync/clock

FILES

/run/systemd/notify

Daemon status notification socket.

/run/systemd/private

Internal communication channel between systemctl(1) and the systemd process.

/usr/lib/clock-epoch

Its modification time is used for the time epoch.

Added in version 247.

/var/lib/systemd/timesync/clock

Modification time updated by systemd-timesyncd.service(8). Used for the epoch if present.

Added in version 257.

HISTORY

systemd 252

Kernel command-line arguments systemd.unified_cgroup_hierarchy and systemd.legacy_systemd_cgroup_controller were deprecated. Please switch to the unified cgroup hierarchy.

SEE ALSO

systemd Homepage, systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7)

For more information about the concepts and ideas behind systemd, please refer to the Original Design Document.

NOTES

1. Interface Portability and Stability Promise
   • https://systemd.io/PORTABILITY_AND_STABILITY/
2. Container Interface
   • https://systemd.io/CONTAINER_INTERFACE
3. initrd Interface
   • https://systemd.io/INITRD_INTERFACE/
4. Control Groups v2
   • https://docs.kernel.org/admin-guide/cgroup-v2.html
5. XDG Base Directory specification
   • https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
6. It is recommended for other tools to set and check $SUDO_UID as appropriate.
7. Known Environment Variables
   • https://systemd.io/ENVIRONMENT
8. System and Service Credentials
   • https://systemd.io/CREDENTIALS
9. systemd Homepage
   • https://systemd.io/
10. Original Design Document
    • https://0pointer.de/blog/projects/systemd.html

COLOPHON

This page is part of the systemd project. Information about the project can be found at:

http://www.freedesktop.org/wiki/Software/systemd

If you have a bug report for this manual page, see:

http://www.freedesktop.org/wiki/Software/systemd/#bugreports

This page was obtained from the project's upstream Git repository:

https://github.com/systemd/systemd.git

on 2026-01-16. At that time, the date of the most recent commit found in the repository was 2026-01-16.

If you discover rendering problems in this HTML version of the page, or believe there is a better or more up-to-date source for the page, or have corrections or improvements to the information in this COLOPHON (which is not part of the original manual page), send mail to man-pages@man7.org.

Sidslut

Orginalhemsidan på Engelska :https://man7.org/linux/man-pages/man1/systemd.1.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp som har sponsrat Linux.se med webbhotell.