<?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">

<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 system instance, systemd interprets

the configuration file

<filename>system.conf</filename>, otherwise

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

<citerefentry><refentrytitle>systemd.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>-h</option></term>

<term><option>--help</option></term>

<listitem><para>Prints a short help

text and exits.</para></listitem>

</varlistentry>

<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>--introspect=</option></term>

<listitem><para>Extract D-Bus

interface introspection data. This is

mostly useful at install time

to generate data suitable for the

D-Bus interfaces

repository. Optionally the interface

name for the introspection data may be

specified. If omitted, the

introspection data for all interfaces

is dumped.</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>Tell systemd to run a

system instance (resp. user

instance), even if the process ID is

not 1 (resp. is 1), i.e. systemd is

not (resp. is) run as init process.

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>--sysv-console=</option></term>

<listitem><para>Controls whether

output of SysV init scripts will be

directed to the console. 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>syslog</option>,

<option>kmsg</option>,

<option>syslog-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><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 resp. error output for all

services and sockets, i.e. controls

the default for

<option>StandardOutput=</option>

resp. <option>StandardExecute=</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>syslog</option>,

<option>syslog+console</option>,

<option>kmsg</option>,

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

argument is omitted it defaults to

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

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>Concepts</title>

<para>systemd provides a dependency system between

various entities called "units". 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 or dynamically from system state. 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 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>

</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="http://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><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 host name 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>

</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/share/systemd/system</filename>

and

<filename>/usr/share/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.</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.</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>SIGTERM</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>SIGINT</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>.</para>

<para>systemd user managers

treat this signal the same way as

SIGTERM.</para></listitem>

</varlistentry>

<varlistentry>

<term>SIGWINCH</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>SIGPWR</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>SIGUSR1</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>SIGUSR2</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>systemctl

dump</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term>SIGHUP</term>

<listitem><para>Reloads the complete

daemon configuration. This is mostly

equivalent to <command>systemctl

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

</varlistentry>

<varlistentry>

<term>SIGRTMIN+0</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>SIGRTMIN+1</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>SIGRTMIN+2</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>SIGRTMIN+3</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>SIGRTMIN+4</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>SIGRTMIN+5</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>SIGRTMIN+6</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>SIGRTMIN+13</term>

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

</varlistentry>

<varlistentry>

<term>SIGRTMIN+14</term>

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

</varlistentry>

<varlistentry>

<term>SIGRTMIN+15</term>

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

</varlistentry>

<varlistentry>

<term>SIGRTMIN+16</term>

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

</varlistentry>

<varlistentry>

<term>SIGRTMIN+20</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>SIGRTMIN+21</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>

</variablelist>

</refsect1>

<refsect1>

<title>Environment</title>

<variablelist>

<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 few kernel command line arguments:</para>

<variablelist>

<varlistentry>

<term><varname>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.</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

<literal>-1</literal>.</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. If <option>true</option>

shows terse service status updates on

the console during bootup. Defaults to

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

</varlistentry>

<varlistentry>

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

<listitem><para>Takes a boolean

argument. If <option>true</option>

output of SysV init scripts will be

directed to the console. Defaults to

<option>true</option>, unless

<option>quiet</option> is passed as

kernel command line option in which

case it defaults to

<option>false</option>.</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/error output for

services, with the same effect as the

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

resp. <option>--default-standard-error=</option>

command line arguments described

above.</para></listitem>

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>Sockets and FIFOs</title>

<variablelist>

<varlistentry>

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

<listitem><para>Daemon status

notification socket. This is an AF_UNIX

datagram socket in the Linux abstract

namespace, 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>/var/run/systemd/logger</filename></term>

<listitem><para>Used internally by the

<filename>systemd-logger.service</filename>

unit to connect STDOUT and/or STDERR

of spawned processes to

<citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>

or the kernel log buffer. This is an

AF_UNIX stream socket in the Linux

abstract namespace.</para></listitem>

</varlistentry>

<varlistentry>

<term><filename>/var/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 AF_UNIX datagram

socket in the Linux abstract

namespace.</para></listitem>

</varlistentry>

<varlistentry>

<term><filename>/var/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

AF_UNIX stream socket in the Linux

abstract namespace. 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>

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

<citerefentry><refentrytitle>systemadm</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>7</manvolnum></citerefentry>,

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

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

<citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>

</para>

</refsect1>

</refentry>