/usr/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}
A system and service manager for Linux. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace 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 invoked as init and is not the first process on the machine (PID is not 1), it will execute
telinit and pass all command line arguments unmodified.
init and telinit are
similar when invoked from normal login sessions. See telinit (8)
When run as a system instance, systemd interprets system.conf and the files
in system.conf.d directories.
When run as a user instance, systemd interprets user.conf
and the files in user.conf.d directories. See
systemd-system.conf (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 (i.e.
Requires= and Conflicts=) as
well as ordering dependencies ( After= and Before=
). ordering and requirement
dependencies are orthogonal. If only a requirement dependency
exists between two units (e.g. foo.service
requires bar.service), but no ordering dependency (e.g. foo.service
after bar.service) and both are requested to start,
they will be started in parallel. It is a common pattern that both
requirement and ordering dependencies are placed between two
units. The majority of dependencies are implicitly
created and maintained by systemd. It should be
unnecessary to declare additional dependencies manually,
Application programs and units (via dependencies) may request state changes of units. These requests are encapsulated as 'jobs' and maintained in a job queue. Jobs may succeed or can fail, their execution is ordered based on the ordering dependencies of the units they have been scheduled
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. The unit name is just an symlink for either
graphical.target (for fully-featured boots into the UI) or multi-user.target
(for limited console-only boots for use in embedded or server
environments, or similar; a subset of graphical.target).
It is at the discretion of the administrator to configure it as an
alias to any other target unit. See
systemd.special (7)
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 which are:
inactive ")
It has some form of resource still allocated (e.g. a service unit that is inactive but for which
systemd will automatically load units from disk when
operations are requested for them.
Use systemctl list-units --all
to list units currently loaded. Any
unit for which none of the conditions above applies is unloaded and
its accounting data is flushed, generally not lost, as a journal log record
is generated declaring the consumed resources whenever a unit shuts down.
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
systemd uses this to keep track of
processes. Control group information is maintained in the kernel, and is accessible via the file system
hierarchy (beneath /sys/fs/cgroup/), or in tools such as
systemd-cgls (1)
or
ps (1)
( ps xawf -eo pid,user,cgroup,args
is useful to list processes and the systemd units they belong to.).
systemd has a minimal transaction system: if a unit is requested to start up or shut down it will add it and all its dependencies to a temporary transaction. Then, it will verify if the transaction is consistent (i.e. whether the ordering of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop. Also, systemd tries to suppress non-essential jobs in the transaction that would stop a running service. Finally it is checked whether the jobs of the transaction contradict jobs that have already been queued, and optionally the transaction is aborted then. If all worked out and the transaction is consistent and minimized in its impact it is merged with all already outstanding jobs and added to the run queue. Before executing a requested operation, systemd will verify that it makes sense, fixing it if possible, and only
that transactions are generated independently of a unit's state at runtime. For example, if a start job is requested on an already started unit, it will still generate a transaction and wake up any inactive dependencies (and cause propagation of other jobs as per the defined relationships). This is because the enqueued job is at the time of execution compared to the target unit's state and is marked successful and complete when both satisfy. However, this job also pulls in other dependencies due to the defined relationships and thus leads to, in our example, start jobs for any of those inactive units getting queued as
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/ or /proc/ .
Original Design Document
Interface Portability and Stability Promise .
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) .
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
pkg-config systemd --variable=systemdsystemunitdir/usr/local/lib/systemd/system
and /usr/lib/systemd/system . User configuration always takes precedence.
pkg-config systemd --variable=systemdsystemconfdir returns the
path of the system configuration directory. Packages should
alter the content of these directories only with the
enable and disable commands of the
systemctl (1)
tool. Full list of directories is provided in
systemd.unit (5)
Similar rules apply for the user unit
directories.
XDG Base Directory specification
is followed to find units. Applications should place their 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 . The
enable and disable commands of the
systemctl (1)
tool can handle both global (i.e. for all users) and private
(for one user) enabling/disabling of units. Full list of
directories is provided in
systemd.unit (5)
SIGTERM
| manager serializes its state, reexecutes itself and
deserializes the saved state again. Similar
to systemctl daemon-reexec
systemd user managers will start the exit.target unit . Similar to
systemctl --user start exit.target --job-mode=replace-irreversibly
|
SIGINT
| manager will start the ctrl-alt-del.target
unit. Similar to
systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly
. If this signal is received more than 7 times per 2s, an immediate reboot is triggered.
on the console will trigger this signal. if a reboot is hanging, pressing
Ctrl + Alt + Del
more than 7 times in 2 seconds is a safe way to trigger an immediate reboot.
Systemd user managers treat this signal the same way as SIGTERM
|
SIGWINCH
| manager will start the kbrequest.target unit. Similar to
systemctl start kbrequest.target
This signal is ignored by systemd user??? (sic) |
SIGPWR
| manager will start the sigpwr.target unit. Similar to systemctl start sigpwr.target
|
SIGUSR1
| manager will reconnect to the D-Bus |
SIGUSR2
| manager will log its complete state in human-readable form.
the same as printed by
systemd-analyze dump
|
SIGHUP
|
Reloads the complete daemon configuration. Similar to
systemctl daemon-reload
|
SIGRTMIN+0
|
Enters default mode, starts the default.target
unit. Similar to systemctl isolate default.target
|
SIGRTMIN+1
|
Enters rescue mode, starts the rescue.target
unit. This is similar to
systemctl isolate rescue.target
|
SIGRTMIN+2
|
Enters emergency mode, starts the
emergency.service
unit. This is similar to systemctl isolate emergency.service
|
SIGRTMIN+3
|
Halts the machine, starts the halt.target unit. This is similar to
systemctl start halt.target --job-mode=replace-irreversibly
|
SIGRTMIN+4
|
starts the poweroff.target unit. This is similar to
systemctl start poweroff.target --job-mode=replace-irreversibly
|
SIGRTMIN+5
|
Reboots the machine, starts the
reboot.target
unit. This is similar to
systemctl start reboot.target --job-mode=replace-irreversibly
|
SIGRTMIN+6
|
Reboots the machine via kexec, starts the
kexec.target unit. This is similar to
systemctl start kexec.target
--job-mode=replace-irreversibly
|
SIGRTMIN+13
SIGRTMIN+14SIGRTMIN+15SIGRTMIN+16SIGRTMIN+20
|
Enables display of status messages on the console, as controlled via
systemd.show_status=1 on the kernel command line.
|
SIGRTMIN+21
|
Disables display of status messages on the console, as controlled via
systemd.show_status=0 on the kernel command line.
|
SIGRTMIN+22
|
Sets the service manager's log level to " debug ", in a fashion equivalent to
systemd.log_level=debug on the kernel command line.
|
SIGRTMIN+23
|
Restores the log level to its configured value. derived from – in order
of priority – the value specified with
systemd.log-level= on the kernel command line, or the
value specified with LogLevel=
in the configuration file, or the built-in default of
" info ".
|
SIGRTMIN+24
| Immediately exits the manager (only available
SIGRTMIN+25
manager will reexecute itself. This is similar to
The systemd system manager treats this signal the same way as |
SIGRTMIN+26
|
Restores the log target to its configured value, from – in
order of priority – the value specified with
systemd.log-target=
on the kernel command line, or the value specified with
LogTarget= in the configuration file, or the built-in default.
|
SIGRTMIN+27
,SIGRTMIN+28
|
Sets the log target to " console " on SIGRTMIN+27
(or " kmsg " on SIGRTMIN+28), in a fashion equivalent to
systemd.log_target=console
(or systemd.log_target=kmsg on
SIGRTMIN+28
) on the kernel command line.
|
key=value " assignments on the kernel command line are turned into environment
variables for PID 1). For the user manager, the system manager sets the environment as described in the
"Environment Variables in Spawned Processes" section of
(5)
. The DefaultEnvironment= setting in the system manager applies to all services including
user@.service
. Additional entries may be configured (as for any other service) through the Environment= and
EnvironmentFile= settings for user@.service (see (5)
). Additional environment variables may be set through the
ManagerEnvironment= setting in
(5)
and (5) .
Some of the variables understood by systemd :
$SYSTEMD_LOG_LEVEL
The maximum log level of emitted messages (messages with a higher
log level, i.e. less important ones, will be suppressed). Either one of (in order of decreasing
importance)
emerg , alert , crit err ,
warning , notice info , debug
, or an integer in the range 0…7. See
(3)
This can be overridden with --log-level=
$SYSTEMD_LOG_COLOR
A boolean. If true, messages written to the tty will be colored according to priority.
This can be overridden with --log-color=
$SYSTEMD_LOG_TIME
A boolean. If true, console log messages will be prefixed with a timestamp.
This can be overridden with --log-time=
$SYSTEMD_LOG_LOCATION
A boolean. If true, messages will be prefixed with a filename and line number in the source code where the message originates.
This can be overridden with --log-location=
$SYSTEMD_LOG_TID
A boolean. If true, messages will be prefixed with the current numerical thread ID (TID).
$SYSTEMD_LOG_TARGET
The destination for log messages. One of
console (log to the attached tty),
console-prefixed (log to
the attached tty but with prefixes encoding the log level and "facility", see
(3)
kmsg (log to the kernel circular log buffer),
journal (log to the journal),
journal-or-kmsg (log to the journal if available, and to kmsg otherwise),
auto (determine the appropriate log target automatically, the default),
null (disable log output).
This can be overridden with --log-target=
$XDG_CONFIG_HOME ,
$XDG_CONFIG_DIRS ,
$XDG_DATA_HOME ,
$XDG_DATA_DIRS
The systemd user manager uses these variables in accordance to the XDG Base Directory specification to find its configuration.
$SYSTEMD_UNIT_PATH , $SYSTEMD_GENERATOR_PATH ,
$SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Controls where systemd looks for unit files and
These variables may contain a list of paths, separated by colons
(" : "). When set, if the list ends with an empty
component (" ...: "), this list is prepended to the
usual set of paths. Otherwise, the specified list replaces the usual
set of paths.
$SYSTEMD_PAGER
Pager to use when --no-pager is not given; overrides
$PAGER . If neither $SYSTEMD_PAGER nor
$PAGER are set, a set of well-known pager implementations are tried in turn, including
(1)
and
(1)
, until one is found.
If no pager implementation is discovered no pager is invoked. Setting this environment variable
to an empty string or the value " cat " is equivalent to passing
--no-pager
If
$SYSTEMD_PAGERSECURE is not set,
$SYSTEMD_PAGER (as well as $PAGER) will be silently ignored.
$SYSTEMD_LESS
Override the options passed to less (by default " FRSXMK ").
K
X
See (1)
$SYSTEMD_LESSCHARSET
Override the charset passed to less
(by default " utf-8 ", if
the invoking terminal is determined to be UTF-8 compatible).
$SYSTEMD_PAGERSECURE
Takes a boolean argument. When true, the "secure" mode of the pager is enabled; if
false, disabled. If not set , secure mode is enabled
if the effective UID is not the same as the owner of the login session, see
(2)
and (3) In secure mode,
LESSSECURE=1
will be set when invoking the pager, and the pager shall
disable commands that open or create new files or start new subprocesses. When
$SYSTEMD_PAGERSECURE
is not set , pagers which are not known to implement
secure mode will not be used. (Currently only
(1) implements secure mode.)
When commands are invoked with elevated privileges, for example under
(8) or
(1)
, care must be taken to ensure that unintended interactive features are not enabled. "Secure" mode for the
pager may be enabled automatically as describe above. Setting
SYSTEMD_PAGERSECURE=0
or not removing it from the inherited environment allows the user to invoke arbitrary commands. Note
that if the $SYSTEMD_PAGER or
$PAGER
variables are to be honoured, $SYSTEMD_PAGERSECURE
must be set too. It might be reasonable to completely disable the pager using
--no-pager instead.
$SYSTEMD_COLORS
Takes a boolean argument. When true, systemd and related utilities
will use colors in their output, otherwise the output will be monochrome. Additionally, the variable can
take one of the following special values: "
16 ", " 256 " to restrict the use
of colors to the base 16 or 256 ANSI colors, respectively. This can be specified to override the automatic
decision based on $TERM and what the console is connected to.
$SYSTEMD_URLIFY
The value must be a boolean. Controls whether clickable links should be generated in
the output for terminal emulators supporting this. This can be specified to override the decision that
systemd makes based on $TERM and other conditions.
$LISTEN_PID ,
$LISTEN_FDS ,
$LISTEN_FDNAMES
Set by systemd for supervised processes during socket-based activation. See (3)
$NOTIFY_SOCKET
Set by systemd for supervised processes for status and start-up completion notification. See (3)
For further environment variables Known Environment Variables .
When run as the system instance, systemd
arguments are parsed from
/proc/cmdline and from the " SystemdOptions " EFI variable (on EFI systems) instead. Options from
/proc/cmdline have higher priority.
systemd.unit= , rd.systemd.unit=
Overrides the unit to activate on boot. Defaults to
default.target
. This may be used to temporarily boot into a different boot unit, for example
rescue.target or emergency.service
. See (7)
rd. " is honored only in the
initrd, while the one that is not prefixed only in the main system.
systemd.dump_core
Takes a boolean argument or enables the option if specified without an argument. If enabled, the systemd manager (PID 1) dumps core when
systemd.crash_chvt
Takes a positive integer, or a boolean argument. Can be also specified without an argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes. Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual
systemd.crash_shell
Takes a boolean argument or enables the option if specified without an argument. If enabled, the system manager (PID 1) spawns a shell when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults to disabled, for security reasons, as the shell is not protected by password <
Takes a boolean argument or enables the option if specified without an argument. If enabled, the system manager (PID 1) will reboot the machine automatically when it crashes, after a 10s delay. Otherwise, the system will hang indefinitely. Defaults to disabled, in order to avoid a reboot loop. If combined with
systemd.crash_shell
, the
system is rebooted after the shell exits.
systemd.confirm_spawn
Takes a boolean argument or a path to the virtual console where the confirmation messages should be emitted. Can be also specified without an argument, with the same effect as a positive boolean. If enabled, the system manager (PID 1) asks for confirmation when spawning processes using
/dev/console
. If a path or a console name (such as
"
ttyS0
") is provided, the virtual console pointed to by this
path or described by the give name will be used instead. Defaults to disabled.
systemd.service_watchdogs=
Takes a boolean argument. If disabled, all service runtime
watchdogs (
WatchdogSec=
) and emergency actions (e.g.
OnFailure=
or
StartLimitAction=
) are
ignored by the system manager (PID 1); see
(5)
Defaults to enabled, i.e. watchdogs and failure actions are processed
normally. The hardware watchdog is not affected by this
option.
systemd.show_status
Takes a boolean argument or the constants
error
and
auto
. Can be also specified without an argument, with the same effect as a
positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the
console during bootup. With
error
, only messages about failures are shown, but
boot is otherwise quiet.
auto
behaves like
false
until there is
a significant delay in boot. Defaults to enabled, unless
quiet
is passed as kernel
command line option, in which case it defaults to
error
. If specified overrides
the system manager configuration file option
ShowStatus=
, see
(5)
systemd.status_unit_format=
Takes
name
,
description
or
combined
as the value. If
name
, the system manager will use unit
names in status messages. If
combined
, the system manager will use unit names and
description in status messages. When specified, overrides the system manager configuration file
option
StatusUnitFormat=
, see
systemd.log_color
,
systemd.log_level=
,
systemd.log_location
,
systemd.log_target=
,
systemd.log_time
,
systemd.log_tid
Controls log output, with the same effect as the
$SYSTEMD_LOG_COLOR
,
$SYSTEMD_LOG_LEVEL
$SYSTEMD_LOG_LOCATION
,
$SYSTEMD_LOG_TARGET
$SYSTEMD_LOG_TIME
, and
$SYSTEMD_LOG_TID
environment variables
described above.
systemd.log_color
,
systemd.log_location
systemd.log_time
, and
systemd.log_tid=
can be specified without
an argument, with the same effect as a positive boolean.
systemd.default_standard_output=
,
systemd.default_standard_error=
Controls default standard output and error output for services and sockets. That is,
controls the default for
StandardOutput=
and
StandardError=
(see
(5)
for
details). Takes one of
inherit
,
null
,
tty
journal
,
journal+console
,
kmsg
kmsg+console
. If the argument is omitted
systemd.default-standard-output=
defaults to
journal
and
systemd.default-standard-error=
to
inherit
systemd.setenv=
Takes a string argument in the form VARIABLE=VALUE. May be used to set default environment variables to add to forked child processes. May be used more
systemd.machine_id=
Takes a 32 character hex value to be used for setting the machine-id. Intended mostly for network booting where the same machine-id is desired
systemd.set_credential=
Sets a system credential, which can then be propagated to system services using the
LoadCredential=
setting, see
/proc/cmdline
. Thus, this mechanism is not suitable for transferring sensitive
data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private
keys), or in testing/debugging environments.
For further information see System and Service Credentials documentation.
systemd.import_credentials=
Takes a boolean argument. If false disables importing credentials from the kernel
command line, the DMI/SMBIOS OEM string table, the qemu_fw_cfg subsystem or the EFI kernel
quiet
Turn off status output at boot, much like
systemd.show_status=no
would. Note that
this option is also read by the kernel itself and disables
kernel log output. Passing this option hence turns off the
usual output from both the system manager and the kernel.
debug
Turn on debugging output. This is equivalent
to
systemd.log_level=debug
. Note that this
option is also read by the kernel itself and enables kernel
debug output. Passing this option hence turns on the debug
output from both the system manager and the
kernel.
emergency
,
rd.emergency
,
-b
Boot into emergency mode. This is equivalent
to
systemd.unit=emergency.target
or
rd.systemd.unit=emergency.target
, respectively, and
provided for compatibility reasons and to be easier to type.
rescue
,
rd.rescue
,
single
,
s
,
S
,
1
Boot into rescue mode. This is equivalent to
systemd.unit=rescue.target
or
rd.systemd.unit=rescue.target
, respectively, and
provided for compatibility reasons and to be easier to type.
2
,
3
,
4
,
5
Boot into the specified legacy SysV runlevel.
These are equivalent to
systemd.unit=runlevel2.target
systemd.unit=runlevel3.target
systemd.unit=runlevel4.target
, and
systemd.unit=runlevel5.target
respectively, and provided for compatibility reasons and to be
easier to type.
locale.LANG=
,
locale.LANGUAGE=
,
locale.LC_CTYPE=
,
locale.LC_NUMERIC=
,
locale.LC_TIME=
,
locale.LC_COLLATE=
,
locale.LC_MONETARY=
,
locale.LC_MESSAGES=
,
locale.LC_PAPER=
,
locale.LC_NAME=
,
locale.LC_ADDRESS=
,
locale.LC_TELEPHONE=
,
locale.LC_MEASUREMENT=
,
locale.LC_IDENTIFICATION=
Set the system locale to use. This overrides
the settings in
/etc/locale.conf
. For
more information, see
(5)
and
(7)
For other kernel command line parameters understood by components of the core OS, please refer to (7) .
systemd
is only very rarely invoked directly, since it is started early and is
already running by the time users may interact with it. Normally, tools like
(1)
are used to
give commands to the manager. Since
systemd
is usually not invoked directly, the
options listed below are mostly useful for debugging and special purposes.