<?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 Session 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 session 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>

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

<listitem><para>Tell systemd to run in

a particular mode. Argument is one of

<option>system</option>,

<option>session</option>. Normally it

should not be necessary to pass this

option, as systemd automatically

detects the mode it is started

in. This call is hence of little use

except for

debugging.</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>--confirm-spawn</option></term>

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

</varlistentry>

<varlistentry>

<term><option>--introspect=</option></term>

<listitem><para>Extract D-Bus

interface introspection data. This is

mostly useful at build 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>--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-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-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>

</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 maintainance. 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), or inactive (meaning

stopped, unbound, unplugged, ...), as well is in the

process of being activated or deactivated,

i.e. between the two states. 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.automount</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 encapsulated memory swap

partitions or files of the operating

systemd. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>

<listitem><para>Path units may be used

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 you may find in

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

<para>On boot systemd activates the target unit

<filename>default.target</filename> whose job it 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>For more information about the concepts and

ideas behind systemd please refer to the <ulink

url="http://0pointer.de/blog/projects/systemd.html">Original

Announcement Document</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

<citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>

tool.</para></listitem>

</varlistentry>

</variablelist>

<variablelist>

<varlistentry>

<term>Session unit directories</term>

<listitem><para>Similar rules apply

for the session 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=systemdsessionunitdir</command>. Global

configuration is done in the

directory reported by

<command>pkg-config systemd

--variable=systemdsessionconfdir</command>. The

<citerefentry><refentrytitle>systemd-install</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 can 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 session managers will

start the

<filename>exit.target</filename> unit

when this signal is received. This is

mostly equivalent to

<command>systemctl --session 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 session 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 session

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>

</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 session

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>Sockets and FIFOs</title>

<variablelist>

<varlistentry>

<term><filename>@/org/freedesktop/systemd1/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>@/org/freedesktop/systemd1/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>@/org/freedesktop/systemd1/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-install</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>