<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->

<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"

"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

<refentry id="systemd"

xmlns:xi="http://www.w3.org/2001/XInclude">

<refentryinfo>

<title>systemd</title>

<productname>systemd</productname>

<authorgroup>

<author>

<contrib>Developer</contrib>

<firstname>Lennart</firstname>

<surname>Poettering</surname>

<email>lennart@poettering.net</email>

</author>

</authorgroup>

</refentryinfo>

<refmeta>

<refentrytitle>systemd</refentrytitle>

<manvolnum>1</manvolnum>

</refmeta>

<refnamediv>

<refname>systemd</refname>

<refname>init</refname>

<refpurpose>systemd system and service manager</refpurpose>

</refnamediv>

<refsynopsisdiv>

<cmdsynopsis>

<command>systemd <arg choice="opt" rep="repeat">OPTIONS</arg></command>

</cmdsynopsis>

<cmdsynopsis>

<command>init <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>

</cmdsynopsis>

</refsynopsisdiv>

<refsect1>

<title>Description</title>

<para>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.</para>

<para>For compatibility with SysV, if systemd is called as

<command>init</command> and a PID that is not 1, it will execute

<command>telinit</command> and pass all command line arguments

unmodified. That means <command>init</command> and

<command>telinit</command> are mostly equivalent when invoked from

normal login sessions. See

<citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>

for more information.</para>

<para>When run as a system instance, systemd interprets the

configuration file <filename>system.conf</filename> and the files

in <filename>system.conf.d</filename> directories; when run as a

user instance, systemd interprets the configuration file

<filename>user.conf</filename> and the files in

<filename>user.conf.d</filename> directories. See

<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for more information.</para>

</refsect1>

<refsect1>

<title>Options</title>

<para>The following options are understood:</para>

<variablelist>

<varlistentry>

<term><option>--test</option></term>

<listitem><para>Determine startup sequence, dump it and exit.

This is an option useful for debugging only.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--dump-configuration-items</option></term>

<listitem><para>Dump understood unit configuration items. This

outputs a terse but complete list of configuration items

understood in unit definition files.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--unit=</option></term>

<listitem><para>Set default unit to activate on startup. If

not specified, defaults to

<filename>default.target</filename>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--system</option></term>

<term><option>--user</option></term>

<listitem><para>For <option>--system</option>, tell systemd to

run a system instance, even if the process ID is not 1, i.e.

systemd is not run as init process. <option>--user</option>

does the opposite, running a user instance even if the process

ID is 1. Normally, it should not be necessary to pass these

options, as systemd automatically detects the mode it is

started in. These options are hence of little use except for

debugging. Note that it is not supported booting and

maintaining a full system with systemd running in

<option>--system</option> mode, but PID not 1. In practice,

passing <option>--system</option> explicitly is only useful in

conjunction with <option>--test</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--dump-core</option></term>

<listitem><para>Enable core dumping on crash. This switch has

no effect when running as user instance. This setting may also

be enabled during boot on the kernel command line via the

<varname>systemd.dump_core=</varname> option, see

below.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--crash-vt=</option><replaceable>VT</replaceable></term>

<listitem><para>Switch to a specific virtual console (VT) on

crash. Takes a positive integer in the range 1–63, or a

boolean argument. If an integer is passed, selects which VT to

switch to. If <constant>yes</constant>, the VT kernel messages

are written to is selected. If <constant>no</constant>, no VT

switch is attempted. This switch has no effect when running as

user instance. This setting may also be enabled during boot,

on the kernel command line via the

<varname>systemd.crash_vt=</varname> option, see

below.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--crash-shell</option></term>

<listitem><para>Run a shell on crash. This switch has no

effect when running as user instance. This setting may also be

enabled during boot, on the kernel command line via the

<varname>systemd.crash_shell=</varname> option, see

below.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--crash-reboot</option></term>

<listitem><para>Automatically reboot the system on crash. This

switch has no effect when running as user instance. This

setting may also be enabled during boot, on the kernel command

line via the <varname>systemd.crash_reboot=</varname> option,

see below.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--confirm-spawn</option></term>

<listitem><para>Ask for confirmation when spawning processes.

This switch has no effect when run as user

instance.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--show-status=</option></term>

<listitem><para>Show terse service status information while

booting. This switch has no effect when run as user instance.

Takes a boolean argument which may be omitted which is

interpreted as <option>true</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--log-target=</option></term>

<listitem><para>Set log target. Argument must be one of

<option>console</option>,

<option>journal</option>,

<option>kmsg</option>,

<option>journal-or-kmsg</option>,

<option>null</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--log-level=</option></term>

<listitem><para>Set log level. As

argument this accepts a numerical log

level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>

symbolic names (lowercase):

<option>emerg</option>,

<option>alert</option>,

<option>crit</option>,

<option>err</option>,

<option>warning</option>,

<option>notice</option>,

<option>info</option>,

<option>debug</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--log-color=</option></term>

<listitem><para>Highlight important log messages. Argument is

a boolean value. If the argument is omitted, it defaults to

<option>true</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--log-location=</option></term>

<listitem><para>Include code location in log messages. This is

mostly relevant for debugging purposes. Argument is a boolean

value. If the argument is omitted it defaults to

<option>true</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><option>--default-standard-output=</option></term>

<term><option>--default-standard-error=</option></term>

<listitem><para>Sets the default output or error output for

all services and sockets, respectively. That is, controls the

default for <option>StandardOutput=</option> and

<option>StandardError=</option> (see

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for details). Takes one of

<option>inherit</option>,

<option>null</option>,

<option>tty</option>,

<option>journal</option>,

<option>journal+console</option>,

<option>syslog</option>,

<option>syslog+console</option>,

<option>kmsg</option>,

<option>kmsg+console</option>. If the

argument is omitted

<option>--default-standard-output=</option> defaults to

<option>journal</option> and

<option>--default-standard-error=</option> to

<option>inherit</option>.</para></listitem>

</varlistentry>

<xi:include href="standard-options.xml" xpointer="help" />

<xi:include href="standard-options.xml" xpointer="version" />

</variablelist>

</refsect1>

<refsect1>

<title>Concepts</title>

<para>systemd provides a dependency system between various

entities called "units" of 12 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

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

however some are created automatically from other configuration,

dynamically from system state or programmatically at runtime.

Units may be "active" (meaning started, bound, plugged in, ...,

depending on the unit type, see below), or "inactive" (meaning

stopped, unbound, unplugged, ...), as well as in the process of

being activated or deactivated, i.e. between the two states (these

states are called "activating", "deactivating"). A special

"failed" state is available as well, which is very similar to

"inactive" and is entered when the service failed in some way

(process returned error code on exit, or crashed, or an operation

timed out). If this state is entered, the cause will be logged,

for later reference. Note that the various unit types may have a

number of additional substates, which are mapped to the five

generalized unit states described here.</para>

<para>The following unit types are available:</para>

<orderedlist>

<listitem><para>Service units, which start and control daemons

and the processes they consist of. For details, see

<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Socket units, which encapsulate local IPC or

network sockets in the system, useful for socket-based

activation. For details about socket units, see

<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

for details on socket-based activation and other forms of

activation, see

<citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Target units are useful to group units, or

provide well-known synchronization points during boot-up, see

<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Device units expose kernel devices in systemd

and may be used to implement device-based activation. For

details, see

<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Mount units control mount points in the file

system, for details see

<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Automount units provide automount capabilities,

for on-demand mounting of file systems as well as parallelized

boot-up. See

<citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Snapshot units can be used to temporarily save

the state of the set of systemd units, which later may be

restored by activating the saved snapshot unit. For more

information, see

<citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Timer units are useful for triggering activation

of other units based on timers. You may find details in

<citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Swap units are very similar to mount units and

encapsulate memory swap partitions or files of the operating

system. They are described in

<citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Path units may be used to activate other

services when file system objects change or are modified. See

<citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Slice units may be used to group units which

manage system processes (such as service and scope units) in a

hierarchical tree for resource management purposes. See

<citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Scope units are similar to service units, but

manage foreign processes instead of starting them as well. See

<citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

</orderedlist>

<para>Units are named as their configuration files. Some units

have special semantics. A detailed list is available in

<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>

<para>systemd knows various kinds of dependencies, including

positive and negative requirement dependencies (i.e.

<varname>Requires=</varname> and <varname>Conflicts=</varname>) as

well as ordering dependencies (<varname>After=</varname> and

<varname>Before=</varname>). NB: ordering and requirement

dependencies are orthogonal. If only a requirement dependency

exists between two units (e.g. <filename>foo.service</filename>

requires <filename>bar.service</filename>), but no ordering

dependency (e.g. <filename>foo.service</filename> after

<filename>bar.service</filename>) 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. Also note that the majority of dependencies are implicitly

created and maintained by systemd. In most cases, it should be

unnecessary to declare additional dependencies manually, however

it is possible to do this.</para>

<para>Application programs and units (via dependencies) may

request state changes of units. In systemd, 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

for.</para>

<para>On boot systemd activates the target unit

<filename>default.target</filename> 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 <filename>graphical.target</filename> (for fully-featured

boots into the UI) or <filename>multi-user.target</filename> (for

limited console-only boots for use in embedded or server

environments, or similar; a subset of graphical.target). However,

it is at the discretion of the administrator to configure it as an

alias to any other target unit. See

<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>

for details about these target units.</para>

<para>Processes systemd spawns are placed in individual Linux

control groups named after the unit which they belong to in the

private systemd hierarchy. (see <ulink

url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>

for more information about control groups, or short "cgroups").

systemd uses this to effectively keep track of processes. Control

group information is maintained in the kernel, and is accessible

via the file system hierarchy (beneath

<filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as

<citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>

or

<citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>

(<command>ps xawf -eo pid,user,cgroup,args</command> is

particularly useful to list all processes and the systemd units

they belong to.).</para>

<para>systemd is compatible with the SysV init system to a large

degree: SysV init scripts are supported and simply read as an

alternative (though limited) configuration file format. The SysV

<filename>/dev/initctl</filename> interface is provided, and

compatibility implementations of the various SysV client tools are

available. In addition to that, various established Unix

functionality such as <filename>/etc/fstab</filename> or the

<filename>utmp</filename> database are supported.</para>

<para>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. Effectively this

means that before executing a requested operation, systemd will

verify that it makes sense, fixing it if possible, and only

failing if it really cannot work.</para>

<para>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

<filename>/sys</filename> or <filename>/proc</filename>.</para>

<para>For more information about the concepts and

ideas behind systemd, please refer to the

<ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>

<para>Note that some but not all interfaces provided

by systemd are covered by the

<ulink url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface

Stability Promise</ulink>.</para>

<para>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

<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>

<para>Systems which invoke systemd in a container or initrd

environment should implement the

<ulink url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or

<ulink url="http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>

specifications, respectively.</para>

</refsect1>

<refsect1>

<title>Directories</title>

<variablelist>

<varlistentry>

<term>System unit directories</term>

<listitem><para>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 <command>pkg-config systemd

--variable=systemdsystemunitdir</command>. Other directories

checked are <filename>/usr/local/lib/systemd/system</filename>

and <filename>/usr/lib/systemd/system</filename>. User

configuration always takes precedence. <command>pkg-config

systemd --variable=systemdsystemconfdir</command> returns the

path of the system configuration directory. Packages should

alter the content of these directories only with the

<command>enable</command> and <command>disable</command>

commands of the

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>

tool. Full list of directories is provided in

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.

</para></listitem>

</varlistentry>

</variablelist>

<variablelist>

<varlistentry>

<term>User unit directories</term>

<listitem><para>Similar rules apply for the user unit

directories. However, here the

<ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG

Base Directory specification</ulink> is followed to find

units. Applications should place their unit files in the

directory returned by <command>pkg-config systemd

--variable=systemduserunitdir</command>. Global configuration

is done in the directory reported by <command>pkg-config

systemd --variable=systemduserconfdir</command>. The

<command>enable</command> and <command>disable</command>

commands of the

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>

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

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.

</para></listitem>

</varlistentry>

</variablelist>

<variablelist>

<varlistentry>

<term>SysV init scripts directory</term>

<listitem><para>The location of the SysV init script directory

varies between distributions. If systemd cannot find a native

unit file for a requested service, it will look for a SysV

init script of the same name (with the

<filename>.service</filename> suffix

removed).</para></listitem>

</varlistentry>

</variablelist>

<variablelist>

<varlistentry>

<term>SysV runlevel link farm directory</term>

<listitem><para>The location of the SysV runlevel link farm

directory varies between distributions. systemd will take the

link farm into account when figuring out whether a service

shall be enabled. Note that a service unit with a native unit

configuration file cannot be started by activating it in the

SysV runlevel link farm.</para></listitem>

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>Signals</title>

<variablelist>

<varlistentry>

<term><constant>SIGTERM</constant></term>

<listitem><para>Upon receiving this signal the systemd system

manager serializes its state, reexecutes itself and

deserializes the saved state again. This is mostly equivalent

to <command>systemctl daemon-reexec</command>.</para>

<para>systemd user managers will start the

<filename>exit.target</filename> unit when this signal is

received. This is mostly equivalent to <command>systemctl

--user start exit.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGINT</constant></term>

<listitem><para>Upon receiving this signal the systemd system

manager will start the

<filename>ctrl-alt-del.target</filename> unit. This is mostly

equivalent to <command>systemctl start

ctl-alt-del.target</command>. If this signal is received more

than 7 times per 2s, an immediate reboot is triggered.

Note that pressing Ctrl-Alt-Del on the console will trigger

this signal. Hence, if a reboot is hanging, pressing

Ctrl-Alt-Del more than 7 times in 2s is a relatively safe way

to trigger an immediate reboot.</para>

<para>systemd user managers treat this signal the same way as

<constant>SIGTERM</constant>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGWINCH</constant></term>

<listitem><para>When this signal is received the systemd

system manager will start the

<filename>kbrequest.target</filename> unit. This is mostly

equivalent to <command>systemctl start

kbrequest.target</command>.</para>

<para>This signal is ignored by systemd user

managers.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGPWR</constant></term>

<listitem><para>When this signal is received the systemd

manager will start the <filename>sigpwr.target</filename>

unit. This is mostly equivalent to <command>systemctl start

sigpwr.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGUSR1</constant></term>

<listitem><para>When this signal is received the systemd

manager will try to reconnect to the D-Bus

bus.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGUSR2</constant></term>

<listitem><para>When this signal is received the systemd

manager will log its complete state in human-readable form.

The data logged is the same as printed by

<command>systemd-analyze dump</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGHUP</constant></term>

<listitem><para>Reloads the complete daemon configuration.

This is mostly equivalent to <command>systemctl

daemon-reload</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+0</constant></term>

<listitem><para>Enters default mode, starts the

<filename>default.target</filename> unit. This is mostly

equivalent to <command>systemctl start

default.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+1</constant></term>

<listitem><para>Enters rescue mode, starts the

<filename>rescue.target</filename> unit. This is mostly

equivalent to <command>systemctl isolate

rescue.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+2</constant></term>

<listitem><para>Enters emergency mode, starts the

<filename>emergency.service</filename> unit. This is mostly

equivalent to <command>systemctl isolate

emergency.service</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+3</constant></term>

<listitem><para>Halts the machine, starts the

<filename>halt.target</filename> unit. This is mostly

equivalent to <command>systemctl start

halt.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+4</constant></term>

<listitem><para>Powers off the machine, starts the

<filename>poweroff.target</filename> unit. This is mostly

equivalent to <command>systemctl start

poweroff.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+5</constant></term>

<listitem><para>Reboots the machine, starts the

<filename>reboot.target</filename> unit. This is mostly

equivalent to <command>systemctl start

reboot.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+6</constant></term>

<listitem><para>Reboots the machine via kexec, starts the

<filename>kexec.target</filename> unit. This is mostly

equivalent to <command>systemctl start

kexec.target</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+13</constant></term>

<listitem><para>Immediately halts the machine.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+14</constant></term>

<listitem><para>Immediately powers off the machine.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+15</constant></term>

<listitem><para>Immediately reboots the machine.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+16</constant></term>

<listitem><para>Immediately reboots the machine with kexec.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+20</constant></term>

<listitem><para>Enables display of status messages on the

console, as controlled via

<varname>systemd.show_status=1</varname> on the kernel command

line.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+21</constant></term>

<listitem><para>Disables display of

status messages on the console, as

controlled via

<varname>systemd.show_status=0</varname>

on the kernel command

line.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+22</constant></term>

<term><constant>SIGRTMIN+23</constant></term>

<listitem><para>Sets the log level to <literal>debug</literal>

(or <literal>info</literal> on

<constant>SIGRTMIN+23</constant>), as controlled via

<varname>systemd.log_level=debug</varname> (or

<varname>systemd.log_level=info</varname> on

<constant>SIGRTMIN+23</constant>) on the kernel command

line.</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+24</constant></term>

<listitem><para>Immediately exits the manager (only available

for --user instances).</para></listitem>

</varlistentry>

<varlistentry>

<term><constant>SIGRTMIN+26</constant></term>

<term><constant>SIGRTMIN+27</constant></term>

<term><constant>SIGRTMIN+28</constant></term>

<listitem><para>Sets the log level to

<literal>journal-or-kmsg</literal> (or

<literal>console</literal> on

<constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on

<constant>SIGRTMIN+28</constant>), as controlled via

<varname>systemd.log_target=journal-or-kmsg</varname> (or

<varname>systemd.log_target=console</varname> on

<constant>SIGRTMIN+27</constant> or

<varname>systemd.log_target=kmsg</varname> on

<constant>SIGRTMIN+28</constant>) on the kernel command

line.</para></listitem>

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>Environment</title>

<variablelist class='environment-variables'>

<varlistentry>

<term><varname>$SYSTEMD_LOG_LEVEL</varname></term>

<listitem><para>systemd reads the log level from this

environment variable. This can be overridden with

<option>--log-level=</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$SYSTEMD_LOG_TARGET</varname></term>

<listitem><para>systemd reads the log target from this

environment variable. This can be overridden with

<option>--log-target=</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$SYSTEMD_LOG_COLOR</varname></term>

<listitem><para>Controls whether systemd highlights important

log messages. This can be overridden with

<option>--log-color=</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$SYSTEMD_LOG_LOCATION</varname></term>

<listitem><para>Controls whether systemd prints the code

location along with log messages. This can be overridden with

<option>--log-location=</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$XDG_CONFIG_HOME</varname></term>

<term><varname>$XDG_CONFIG_DIRS</varname></term>

<term><varname>$XDG_DATA_HOME</varname></term>

<term><varname>$XDG_DATA_DIRS</varname></term>

<listitem><para>The systemd user manager uses these variables

in accordance to the <ulink

url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG

Base Directory specification</ulink> to find its

configuration.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$SYSTEMD_UNIT_PATH</varname></term>

<listitem><para>Controls where systemd looks for unit

files.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>

<listitem><para>Controls where systemd looks for SysV init

scripts.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>

<listitem><para>Controls where systemd looks for SysV init

script runlevel link farms.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$LISTEN_PID</varname></term>

<term><varname>$LISTEN_FDS</varname></term>

<term><varname>$LISTEN_FDNAMES</varname></term>

<listitem><para>Set by systemd for supervised processes during

socket-based activation. See

<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>

for more information. </para></listitem>

</varlistentry>

<varlistentry>

<term><varname>$NOTIFY_SOCKET</varname></term>

<listitem><para>Set by systemd for supervised processes for

status and start-up completion notification. See

<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>

for more information. </para></listitem>

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>Kernel Command Line</title>

<para>When run as system instance systemd parses a number of

kernel command line arguments<footnote><para>If run inside a Linux

container these arguments may be passed as command line arguments

to systemd itself, next to any of the command line options listed

in the Options section above. If run outside of Linux containers,

these arguments are parsed from <filename>/proc/cmdline</filename>

instead.</para></footnote>:</para>

<variablelist class='kernel-commandline-options'>

<varlistentry>

<term><varname>systemd.unit=</varname></term>

<term><varname>rd.systemd.unit=</varname></term>

<listitem><para>Overrides the unit to activate on boot.

Defaults to <filename>default.target</filename>. This may be

used to temporarily boot into a different boot unit, for

example <filename>rescue.target</filename> or

<filename>emergency.service</filename>. See

<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>

for details about these units. The option prefixed with

<literal>rd.</literal> is honored only in the initial RAM disk

(initrd), while the one that is not prefixed only in the main

system.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.dump_core=</varname></term>

<listitem><para>Takes a boolean argument. If

<option>yes</option>, the systemd manager (PID 1) dumps core

when it crashes. Otherwise, no core dump is created. Defaults

to <option>yes</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.crash_chvt=</varname></term>

<listitem><para>Takes a positive integer, or a boolean

argument. If a positive integer (in the range 1–63) is

specified, the system manager (PID 1) will activate the specified

virtual terminal (VT) when it crashes. Defaults to

<constant>no</constant>, meaning that no such switch is

attempted. If set to <constant>yes</constant>, the VT the

kernel messages are written to is selected.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.crash_shell=</varname></term>

<listitem><para>Takes a boolean argument. If

<option>yes</option>, the system manager (PID 1) spawns a

shell when it crashes, after a 10s delay. Otherwise, no shell

is spawned. Defaults to <option>no</option>, for security

reasons, as the shell is not protected by password

authentication.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.crash_reboot=</varname></term>

<listitem><para>Takes a boolean argument. If

<option>yes</option>, 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

<option>no</option>, in order to avoid a reboot loop. If

combined with <varname>systemd.crash_shell=</varname>, the

system is rebooted after the shell exits.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.confirm_spawn=</varname></term>

<listitem><para>Takes a boolean argument. If

<option>yes</option>, the system manager (PID 1) asks for

confirmation when spawning processes. Defaults to

<option>no</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.show_status=</varname></term>

<listitem><para>Takes a boolean argument or the constant

<constant>auto</constant>. If <option>yes</option>, the

systemd manager (PID 1) shows terse service status updates on

the console during bootup. <constant>auto</constant> behaves

like <option>false</option> until a service fails or there is

a significant delay in boot. Defaults to

<option>yes</option>, unless <option>quiet</option> is passed

as kernel command line option, in which case it defaults to

<constant>auto</constant>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.log_target=</varname></term>

<term><varname>systemd.log_level=</varname></term>

<term><varname>systemd.log_color=</varname></term>

<term><varname>systemd.log_location=</varname></term>

<listitem><para>Controls log output, with the same effect as

the <varname>$SYSTEMD_LOG_TARGET</varname>,

<varname>$SYSTEMD_LOG_LEVEL</varname>,

<varname>$SYSTEMD_LOG_COLOR</varname>,

<varname>$SYSTEMD_LOG_LOCATION</varname> environment variables

described above.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.default_standard_output=</varname></term>

<term><varname>systemd.default_standard_error=</varname></term>

<listitem><para>Controls default standard output and error

output for services, with the same effect as the

<option>--default-standard-output=</option> and

<option>--default-standard-error=</option> command line

arguments described above, respectively.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>systemd.setenv=</varname></term>

<listitem><para>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

than once to set multiple variables.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>quiet</varname></term>

<listitem><para>Turn off status output at boot, much like

<varname>systemd.show_status=false</varname> 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.

</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>debug</varname></term>

<listitem><para>Turn on debugging output. This is equivalent

to <varname>systemd.log_level=debug</varname>. 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.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>emergency</varname></term>

<term><varname>-b</varname></term>

<listitem><para>Boot into emergency mode. This is equivalent

to <varname>systemd.unit=emergency.target</varname> and

provided for compatibility reasons and to be easier to

type.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>rescue</varname></term>

<term><varname>single</varname></term>

<term><varname>s</varname></term>

<term><varname>S</varname></term>

<term><varname>1</varname></term>

<listitem><para>Boot into rescue mode. This is equivalent to

<varname>systemd.unit=rescue.target</varname> and provided for

compatibility reasons and to be easier to

type.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>2</varname></term>

<term><varname>3</varname></term>

<term><varname>4</varname></term>

<term><varname>5</varname></term>

<listitem><para>Boot into the specified legacy SysV runlevel.

These are equivalent to

<varname>systemd.unit=runlevel2.target</varname>,

<varname>systemd.unit=runlevel3.target</varname>,

<varname>systemd.unit=runlevel4.target</varname>, and

<varname>systemd.unit=runlevel5.target</varname>,

respectively, and provided for compatibility reasons and to be

easier to type.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>locale.LANG=</varname></term>

<term><varname>locale.LANGUAGE=</varname></term>

<term><varname>locale.LC_CTYPE=</varname></term>

<term><varname>locale.LC_NUMERIC=</varname></term>

<term><varname>locale.LC_TIME=</varname></term>

<term><varname>locale.LC_COLLATE=</varname></term>

<term><varname>locale.LC_MONETARY=</varname></term>

<term><varname>locale.LC_MESSAGES=</varname></term>

<term><varname>locale.LC_PAPER=</varname></term>

<term><varname>locale.LC_NAME=</varname></term>

<term><varname>locale.LC_ADDRESS=</varname></term>

<term><varname>locale.LC_TELEPHONE=</varname></term>

<term><varname>locale.LC_MEASUREMENT=</varname></term>

<term><varname>locale.LC_IDENTIFICATION=</varname></term>

<listitem><para>Set the system locale to use. This overrides

the settings in <filename>/etc/locale.conf</filename>. For

more information, see

<citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>

and

<citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.

</para></listitem>

</varlistentry>

</variablelist>

<para>For other kernel command line parameters understood by

components of the core OS, please refer to

<citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>

</refsect1>

<refsect1>

<title>Sockets and FIFOs</title>

<variablelist>

<varlistentry>

<term><filename>/run/systemd/notify</filename></term>

<listitem><para>Daemon status notification socket. This is an

<constant>AF_UNIX</constant> datagram socket and is used to

implement the daemon notification logic as implemented by

<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>

</varlistentry>

<varlistentry>

<term><filename>/run/systemd/private</filename></term>

<listitem><para>Used internally as communication channel

between

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>

and the systemd process. This is an

<constant>AF_UNIX</constant> stream socket. This interface is

private to systemd and should not be used in external

projects.</para></listitem>

</varlistentry>

<varlistentry>

<term><filename>/dev/initctl</filename></term>

<listitem><para>Limited compatibility support for the SysV

client interface, as implemented by the

<filename>systemd-initctl.service</filename> unit. This is a

named pipe in the file system. This interface is obsolete and

should not be used in new applications.</para></listitem>

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>See Also</title>

<para>

The <ulink url="http://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,

<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

<citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,

<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,

<citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,

<citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

<citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,

<citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,

<citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>

</para>

</refsect1>

</refentry>