<?xml version='1.0'?> <!--*-nxml-*-->

<!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>Dump core on

crash. This switch has no effect when

run as user

instance.</para></listitem>

</varlistentry>

<varlistentry>

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

<listitem><para>Run shell on

crash. This switch has no effect when

run as user

instance.</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>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 the <ulink

url="http://www.freedesktop.org/wiki/Software/systemd/Generators">Generators

Specification</ulink>.</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 often 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>

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

systemd dumps core when it

crashes. Otherwise, no core dump is

created. Defaults to

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

</varlistentry>

<varlistentry>

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

<listitem><para>Takes a boolean

argument. If <option>true</option>,

systemd spawns a shell when it

crashes. Otherwise, no shell is

spawned. Defaults to

<option>false</option>, for security

reasons, as the shell is not protected

by any password

authentication.</para></listitem>

</varlistentry>

<varlistentry>

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

<listitem><para>Takes an integer

argument. If positive systemd

activates the specified virtual

terminal when it crashes. Defaults to

<constant>-1</constant>.</para></listitem>

</varlistentry>

<varlistentry>

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

<listitem><para>Takes a boolean

argument. If <option>true</option>,

asks for confirmation when spawning

processes. Defaults to

<option>false</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>true</option>, 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>true</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><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>

and

<citerefentry><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/shutdownd</filename></term>

<listitem><para>Used internally by the

<citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>

tool to implement delayed

shutdowns. This is an <constant>AF_UNIX</constant> datagram

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