chiark / gitweb /
man: Clarify when OnFailure= activates after restarts (#7646)
[elogind.git] / man / elogind.xml
1 <?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4
5 <!--
6   SPDX-License-Identifier: LGPL-2.1+
7
8   This file is part of elogind.
9
10   Copyright 2010 Lennart Poettering
11
12   elogind is free software; you can redistribute it and/or modify it
13   under the terms of the GNU Lesser General Public License as published by
14   the Free Software Foundation; either version 2.1 of the License, or
15   (at your option) any later version.
16
17   elogind is distributed in the hope that it will be useful, but
18   WITHOUT ANY WARRANTY; without even the implied warranty of
19   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
20   Lesser General Public License for more details.
21
22   You should have received a copy of the GNU Lesser General Public License
23   along with elogind; If not, see <http://www.gnu.org/licenses/>.
24 -->
25
26 <refentry id="elogind"
27     xmlns:xi="http://www.w3.org/2001/XInclude">
28
29   <refentryinfo>
30     <title>elogind</title>
31     <productname>elogind</productname>
32
33     <authorgroup>
34       <author>
35         <contrib>Developer</contrib>
36         <firstname>Lennart</firstname>
37         <surname>Poettering</surname>
38         <email>lennart@poettering.net</email>
39       </author>
40     </authorgroup>
41   </refentryinfo>
42
43   <refmeta>
44     <refentrytitle>elogind</refentrytitle>
45     <!-- 0 /// elogind is in section 8
46     <manvolnum>1</manvolnum>
47     --><!-- else -->
48     <manvolnum>8</manvolnum>
49     <!-- // 0 -->
50   </refmeta>
51
52   <refnamediv>
53     <!-- 0 /// Well, elogind isn't that much...
54     <refname>systemd</refname>
55     <refname>init</refname>
56     <refpurpose>systemd system and service manager</refpurpose>
57     --><!-- else -->
58     <refname>elogind</refname>
59     <refpurpose>Login manager</refpurpose>
60     <!-- // 0 -->
61   </refnamediv>
62
63   <refsynopsisdiv>
64     <!-- 0 /// elogind has a different synopsis of course...
65     <cmdsynopsis>
66       <command>/usr/lib/systemd/systemd</command>
67       <arg choice="opt" rep="repeat">OPTIONS</arg>
68     </cmdsynopsis>
69     <cmdsynopsis>
70       <command>init</command>
71       <arg choice="opt" rep="repeat">OPTIONS</arg>
72       <arg choice="req">COMMAND</arg>
73     </cmdsynopsis>
74     --><!-- else -->
75     <cmdsynopsis>
76       <command>elogind</command>
77       <arg choice="opt" rep="repeat">OPTIONS</arg>
78       <arg choice="req">COMMAND</arg>
79     </cmdsynopsis>
80     <!-- // 0 -->
81   </refsynopsisdiv>
82
83   <refsect1>
84     <title>Description</title>
85
86     <!-- 0 /// elogind does not need that much explanation.
87     <para>systemd is a system and service manager for Linux operating
88     systems. When run as first process on boot (as PID 1), it acts as
89     init system that brings up and maintains userspace
90     services.</para>
91
92     <para>For compatibility with SysV, if systemd is called as
93     <command>init</command> and a PID that is not 1, it will execute
94     <command>telinit</command> and pass all command line arguments
95     unmodified. That means <command>init</command> and
96     <command>telinit</command> are mostly equivalent when invoked from
97     normal login sessions. See
98     <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
99     for more information.</para>
100
101     <para>When run as a system instance, systemd interprets the
102     configuration file <filename>system.conf</filename> and the files
103     in <filename>system.conf.d</filename> directories; when run as a
104     user instance, systemd interprets the configuration file
105     <filename>user.conf</filename> and the files in
106     <filename>user.conf.d</filename> directories. See
107     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
108     for more information.</para>
109     --><!-- else -->
110     <para><command>elogind</command> is a system service that
111     manages user logins. It is responsible for:</para>
112
113     <itemizedlist>
114       <listitem><para>Keeping track of users and sessions, their
115       processes and their idle state</para></listitem>
116
117       <listitem><para>Providing PolicyKit-based access for users to
118       operations such as system shutdown or sleep</para></listitem>
119
120       <listitem><para>Implementing a shutdown/sleep inhibition logic
121       for applications</para></listitem>
122
123       <listitem><para>Handling of power/sleep hardware
124       keys</para></listitem>
125
126       <listitem><para>Multi-seat management</para></listitem>
127
128       <listitem><para>Session switch management</para></listitem>
129
130       <listitem><para>Device access management for
131       users</para></listitem>
132
133     </itemizedlist>
134
135     <para>User sessions are registered in elogind via the
136     <citerefentry><refentrytitle>pam_elogind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
137     PAM module.</para>
138
139     <para>See
140     <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
141     for information about the configuration of this service.</para>
142
143     <para>See <ulink
144     url="http://www.freedesktop.org/wiki/Software/systemd/multiseat">Multi-Seat
145     on Linux</ulink> for an introduction into basic concepts of logind
146     such as users, sessions and seats.</para>
147
148     <para>See the <ulink
149     url="http://www.freedesktop.org/wiki/Software/systemd/logind">
150     logind D-Bus API Documentation</ulink> for information about the
151     APIs <filename>logind</filename> provides.</para>
152
153     <para>For more information on the inhibition logic see the <ulink
154     url="http://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor
155     Lock Developer Documentation</ulink>.</para>
156   <!-- // 0 -->
157   </refsect1>
158
159   <refsect1>
160     <title>Options</title>
161
162     <para>The following options are understood:</para>
163
164     <variablelist>
165     <!-- 0 /// This list is much shorter with elogind of course.
166       <varlistentry>
167         <term><option>&#x2D;&#x2D;test</option></term>
168
169         <listitem><para>Determine startup sequence, dump it and exit.
170         This is an option useful for debugging only.</para></listitem>
171       </varlistentry>
172       <varlistentry>
173         <term><option>&#x2D;&#x2D;dump-configuration-items</option></term>
174
175         <listitem><para>Dump understood unit configuration items. This
176         outputs a terse but complete list of configuration items
177         understood in unit definition files.</para></listitem>
178       </varlistentry>
179       <varlistentry>
180         <term><option>&#x2D;&#x2D;unit=</option></term>
181
182         <listitem><para>Set default unit to activate on startup. If
183         not specified, defaults to
184         <filename>default.target</filename>.</para></listitem>
185       </varlistentry>
186       <varlistentry>
187         <term><option>&#x2D;&#x2D;system</option></term>
188         <term><option>&#x2D;&#x2D;user</option></term>
189
190         <listitem><para>For <option>&#x2D;&#x2D;system</option>, tell systemd to
191         run a system instance, even if the process ID is not 1, i.e.
192         systemd is not run as init process. <option>&#x2D;&#x2D;user</option>
193         does the opposite, running a user instance even if the process
194         ID is 1. Normally, it should not be necessary to pass these
195         options, as systemd automatically detects the mode it is
196         started in. These options are hence of little use except for
197         debugging. Note that it is not supported booting and
198         maintaining a full system with systemd running in
199         <option>&#x2D;&#x2D;system</option> mode, but PID not 1. In practice,
200         passing <option>&#x2D;&#x2D;system</option> explicitly is only useful in
201         conjunction with <option>&#x2D;&#x2D;test</option>.</para></listitem>
202       </varlistentry>
203       <varlistentry>
204         <term><option>&#x2D;&#x2D;dump-core</option></term>
205
206         <listitem><para>Enable core dumping on crash. This switch has
207         no effect when running as user instance. This setting may also
208         be enabled during boot on the kernel command line via the
209         <varname>systemd.dump_core=</varname> option, see
210         below.</para></listitem>
211       </varlistentry>
212
213       <varlistentry>
214         <term><option>&#x2D;&#x2D;crash-vt=</option><replaceable>VT</replaceable></term>
215
216         <listitem><para>Switch to a specific virtual console (VT) on
217         crash. Takes a positive integer in the range 1–63, or a
218         boolean argument. If an integer is passed, selects which VT to
219         switch to. If <constant>yes</constant>, the VT kernel messages
220         are written to is selected. If <constant>no</constant>, no VT
221         switch is attempted. This switch has no effect when running as
222         user instance. This setting may also be enabled during boot,
223         on the kernel command line via the
224         <varname>systemd.crash_vt=</varname> option, see
225         // 0 -->
226         <!-- FIXME: there is no crash_vt command line option? -->
227         <!-- 0 /// elogind check_tree.pl can not mangle closed comments.
228         below.</para></listitem>
229       </varlistentry>
230
231       <varlistentry>
232         <term><option>&#x2D;&#x2D;crash-shell</option></term>
233
234         <listitem><para>Run a shell on crash. This switch has no
235         effect when running as user instance. This setting may also be
236         enabled during boot, on the kernel command line via the
237         <varname>systemd.crash_shell=</varname> option, see
238         below.</para></listitem>
239       </varlistentry>
240
241       <varlistentry>
242         <term><option>&#x2D;&#x2D;crash-reboot</option></term>
243
244         <listitem><para>Automatically reboot the system on crash. This
245         switch has no effect when running as user instance. This
246         setting may also be enabled during boot, on the kernel command
247         line via the <varname>systemd.crash_reboot=</varname> option,
248         see below.</para></listitem>
249       </varlistentry>
250
251       <varlistentry>
252         <term><option>&#x2D;&#x2D;confirm-spawn</option></term>
253
254         <listitem><para>Ask for confirmation when spawning processes.
255         This switch has no effect when run as user
256         instance.</para></listitem>
257       </varlistentry>
258       <varlistentry>
259         <term><option>&#x2D;&#x2D;show-status=</option></term>
260
261         <listitem><para>Takes a boolean argument or the special value <constant>auto</constant>. If on, terse unit
262         status information is shown on the console during boot-up and shutdown. If off, no such status information is
263         shown. If set to <constant>auto</constant> behavior is similar to off, except that it is automatically switched
264         to on, as soon as the first unit failure or significant boot delay is encountered. This switch has no effect
265         when invoked as user instance. If specified, overrides both the kernel command line setting
266         <varname>systemd.show_status=</varname> (see below) and the configuration file option
267         <option>ShowStatus=</option>, see
268         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
269       </varlistentry>
270       <varlistentry>
271         <term><option>&#x2D;&#x2D;log-target=</option></term>
272
273         <listitem><para>Set log target. Argument must be one of
274         <option>console</option>,
275         <option>journal</option>,
276         <option>kmsg</option>,
277         <option>journal-or-kmsg</option>,
278         <option>null</option>.</para></listitem>
279       </varlistentry>
280       <varlistentry>
281         <term><option>&#x2D;&#x2D;log-level=</option></term>
282
283         <listitem><para>Set log level. As
284         argument this accepts a numerical log
285         level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
286         symbolic names (lowercase):
287         <option>emerg</option>,
288         <option>alert</option>,
289         <option>crit</option>,
290         <option>err</option>,
291         <option>warning</option>,
292         <option>notice</option>,
293         <option>info</option>,
294         <option>debug</option>.</para></listitem>
295       </varlistentry>
296       <varlistentry>
297         <term><option>&#x2D;&#x2D;log-color=</option></term>
298
299         <listitem><para>Highlight important log messages. Argument is
300         a boolean value. If the argument is omitted, it defaults to
301         <option>true</option>.</para></listitem>
302       </varlistentry>
303       <varlistentry>
304         <term><option>&#x2D;&#x2D;log-location=</option></term>
305
306         <listitem><para>Include code location in log messages. This is
307         mostly relevant for debugging purposes. Argument is a boolean
308         value. If the argument is omitted it defaults to
309         <option>true</option>.</para></listitem>
310       </varlistentry>
311       <varlistentry>
312         <term><option>&#x2D;&#x2D;default-standard-output=</option></term>
313         <term><option>&#x2D;&#x2D;default-standard-error=</option></term>
314
315         <listitem><para>Sets the default output or error output for
316         all services and sockets, respectively. That is, controls the
317         default for <option>StandardOutput=</option> and
318         <option>StandardError=</option> (see
319         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
320         for details). Takes one of
321         <option>inherit</option>,
322         <option>null</option>,
323         <option>tty</option>,
324         <option>journal</option>,
325         <option>journal+console</option>,
326         <option>syslog</option>,
327         <option>syslog+console</option>,
328         <option>kmsg</option>,
329         <option>kmsg+console</option>.  If the
330         argument is omitted
331         <option>&#x2D;&#x2D;default-standard-output=</option> defaults to
332         <option>journal</option> and
333         <option>&#x2D;&#x2D;default-standard-error=</option> to
334         <option>inherit</option>.</para></listitem>
335       </varlistentry>
336
337       <varlistentry>
338         <term><option>&#x2D;&#x2D;machine-id=</option></term>
339
340         <listitem><para>Override the machine-id set on the hard drive,
341         useful for network booting or for containers. May not be set
342         to all zeros.</para></listitem>
343       </varlistentry>
344
345       <xi:include href="standard-options.xml" xpointer="help" />
346       <xi:include href="standard-options.xml" xpointer="version" />
347       else -->
348       <varlistentry>
349         <term><option>-D</option></term>
350         <term><option>--daemon</option></term>
351
352         <listitem><para>Daemonize elogind by double-forking
353         into background.</para></listitem>
354       </varlistentry>
355
356       <varlistentry>
357         <term><option>-h</option></term>
358         <term><option>--help</option></term>
359
360         <listitem><para>Show the helpt text and exit.</para></listitem>
361       </varlistentry>
362       <!-- // 0 -->
363     </variablelist>
364   </refsect1>
365
366   <!-- 0 /// The whole concpets section is unneeded in elogind
367   <refsect1>
368     <title>Concepts</title>
369
370     <para>systemd provides a dependency system between various
371     entities called "units" of 11 different types. Units encapsulate
372     various objects that are relevant for system boot-up and
373     maintenance. The majority of units are configured in unit
374     configuration files, whose syntax and basic set of options is
375     described in
376     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
377     however some are created automatically from other configuration,
378     dynamically from system state or programmatically at runtime.
379     Units may be "active" (meaning started, bound, plugged in, …,
380     depending on the unit type, see below), or "inactive" (meaning
381     stopped, unbound, unplugged, …), as well as in the process of
382     being activated or deactivated, i.e. between the two states (these
383     states are called "activating", "deactivating"). A special
384     "failed" state is available as well, which is very similar to
385     "inactive" and is entered when the service failed in some way
386     (process returned error code on exit, or crashed, an operation
387     timed out, or after too many restarts). If this state is entered,
388     the cause will be logged, for later reference. Note that the
389     various unit types may have a number of additional substates,
390     which are mapped to the five generalized unit states described
391     here.</para>
392
393     <para>The following unit types are available:</para>
394
395     <orderedlist>
396       <listitem><para>Service units, which start and control daemons
397       and the processes they consist of. For details, see
398       <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
399
400       <listitem><para>Socket units, which encapsulate local IPC or
401       network sockets in the system, useful for socket-based
402       activation. For details about socket units, see
403       <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
404       for details on socket-based activation and other forms of
405       activation, see
406       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
407
408       <listitem><para>Target units are useful to group units, or
409       provide well-known synchronization points during boot-up, see
410       <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
411
412       <listitem><para>Device units expose kernel devices in systemd
413       and may be used to implement device-based activation. For
414       details, see
415       <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
416
417       <listitem><para>Mount units control mount points in the file
418       system, for details see
419       <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
420
421       <listitem><para>Automount units provide automount capabilities,
422       for on-demand mounting of file systems as well as parallelized
423       boot-up. See
424       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
425
426       <listitem><para>Timer units are useful for triggering activation
427       of other units based on timers. You may find details in
428       <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
429
430       <listitem><para>Swap units are very similar to mount units and
431       encapsulate memory swap partitions or files of the operating
432       system. They are described in
433       <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
434
435       <listitem><para>Path units may be used to activate other
436       services when file system objects change or are modified. See
437       <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
438
439       <listitem><para>Slice units may be used to group units which
440       manage system processes (such as service and scope units) in a
441       hierarchical tree for resource management purposes. See
442       <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
443
444       <listitem><para>Scope units are similar to service units, but
445       manage foreign processes instead of starting them as well. See
446       <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
447
448     </orderedlist>
449
450     <para>Units are named as their configuration files. Some units
451     have special semantics. A detailed list is available in
452     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
453
454     <para>systemd knows various kinds of dependencies, including
455     positive and negative requirement dependencies (i.e.
456     <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
457     well as ordering dependencies (<varname>After=</varname> and
458     <varname>Before=</varname>). NB: ordering and requirement
459     dependencies are orthogonal. If only a requirement dependency
460     exists between two units (e.g. <filename>foo.service</filename>
461     requires <filename>bar.service</filename>), but no ordering
462     dependency (e.g. <filename>foo.service</filename> after
463     <filename>bar.service</filename>) and both are requested to start,
464     they will be started in parallel. It is a common pattern that both
465     requirement and ordering dependencies are placed between two
466     units. Also note that the majority of dependencies are implicitly
467     created and maintained by systemd. In most cases, it should be
468     unnecessary to declare additional dependencies manually, however
469     it is possible to do this.</para>
470
471     <para>Application programs and units (via dependencies) may
472     request state changes of units. In systemd, these requests are
473     encapsulated as 'jobs' and maintained in a job queue. Jobs may
474     succeed or can fail, their execution is ordered based on the
475     ordering dependencies of the units they have been scheduled
476     for.</para>
477
478     <para>On boot systemd activates the target unit
479     <filename>default.target</filename> whose job is to activate
480     on-boot services and other on-boot units by pulling them in via
481     dependencies. Usually, the unit name is just an alias (symlink) for
482     either <filename>graphical.target</filename> (for fully-featured
483     boots into the UI) or <filename>multi-user.target</filename> (for
484     limited console-only boots for use in embedded or server
485     environments, or similar; a subset of graphical.target). However,
486     it is at the discretion of the administrator to configure it as an
487     alias to any other target unit. See
488     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
489     for details about these target units.</para>
490
491     <para>Processes systemd spawns are placed in individual Linux
492     control groups named after the unit which they belong to in the
493     private systemd hierarchy. (see <ulink
494     url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
495     for more information about control groups, or short "cgroups").
496     systemd uses this to effectively keep track of processes. Control
497     group information is maintained in the kernel, and is accessible
498     via the file system hierarchy (beneath
499     <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as
500     <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>
501     or
502     <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
503     (<command>ps xawf -eo pid,user,cgroup,args</command> is
504     particularly useful to list all processes and the systemd units
505     they belong to.).</para>
506
507     <para>systemd is compatible with the SysV init system to a large
508     degree: SysV init scripts are supported and simply read as an
509     alternative (though limited) configuration file format. The SysV
510     <filename>/dev/initctl</filename> interface is provided, and
511     compatibility implementations of the various SysV client tools are
512     available. In addition to that, various established Unix
513     functionality such as <filename>/etc/fstab</filename> or the
514     <filename>utmp</filename> database are supported.</para>
515
516     <para>systemd has a minimal transaction system: if a unit is
517     requested to start up or shut down it will add it and all its
518     dependencies to a temporary transaction. Then, it will verify if
519     the transaction is consistent (i.e. whether the ordering of all
520     units is cycle-free). If it is not, systemd will try to fix it up,
521     and removes non-essential jobs from the transaction that might
522     remove the loop. Also, systemd tries to suppress non-essential
523     jobs in the transaction that would stop a running service. Finally
524     it is checked whether the jobs of the transaction contradict jobs
525     that have already been queued, and optionally the transaction is
526     aborted then. If all worked out and the transaction is consistent
527     and minimized in its impact it is merged with all already
528     outstanding jobs and added to the run queue. Effectively this
529     means that before executing a requested operation, systemd will
530     verify that it makes sense, fixing it if possible, and only
531     failing if it really cannot work.</para>
532
533     <para>systemd contains native implementations of various tasks
534     that need to be executed as part of the boot process. For example,
535     it sets the hostname or configures the loopback network device. It
536     also sets up and mounts various API file systems, such as
537     <filename>/sys</filename> or <filename>/proc</filename>.</para>
538
539     <para>For more information about the concepts and
540     ideas behind systemd, please refer to the
541     <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
542
543     <para>Note that some but not all interfaces provided
544     by systemd are covered by the
545     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
546     Stability Promise</ulink>.</para>
547
548     <para>Units may be generated dynamically at boot and system
549     manager reload time, for example based on other configuration
550     files or parameters passed on the kernel command line. For details, see
551     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
552
553     <para>Systems which invoke systemd in a container or initrd
554     environment should implement the
555     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
556     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
557     specifications, respectively.</para>
558   </refsect1>
559   // 0 -->
560
561   <!-- 0 /// The whole directories section is unneeded in elogind
562   <refsect1>
563     <title>Directories</title>
564
565     <variablelist>
566       <varlistentry>
567         <term>System unit directories</term>
568
569         <listitem><para>The systemd system manager reads unit
570         configuration from various directories. Packages that want to
571         install unit files shall place them in the directory returned
572         by <command>pkg-config systemd
573         &#x2D;&#x2D;variable=systemdsystemunitdir</command>. Other directories
574         checked are <filename>/usr/local/lib/systemd/system</filename>
575         and <filename>/usr/lib/systemd/system</filename>. User
576         configuration always takes precedence. <command>pkg-config
577         systemd &#x2D;&#x2D;variable=systemdsystemconfdir</command> returns the
578         path of the system configuration directory. Packages should
579         alter the content of these directories only with the
580         <command>enable</command> and <command>disable</command>
581         commands of the
582         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
583         tool. Full list of directories is provided in
584         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
585         </para></listitem>
586       </varlistentry>
587     </variablelist>
588
589     <variablelist>
590       <varlistentry>
591         <term>User unit directories</term>
592
593         <listitem><para>Similar rules apply for the user unit
594         directories. However, here the
595         <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
596         Base Directory specification</ulink> is followed to find
597         units. Applications should place their unit files in the
598         directory returned by <command>pkg-config systemd
599         &#x2D;&#x2D;variable=systemduserunitdir</command>. Global configuration
600         is done in the directory reported by <command>pkg-config
601         systemd &#x2D;&#x2D;variable=systemduserconfdir</command>. The
602         <command>enable</command> and <command>disable</command>
603         commands of the
604         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
605         tool can handle both global (i.e. for all users) and private
606         (for one user) enabling/disabling of units. Full list of
607         directories is provided in
608         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
609         </para></listitem>
610       </varlistentry>
611     </variablelist>
612
613     <variablelist>
614       <varlistentry>
615         <term>SysV init scripts directory</term>
616
617         <listitem><para>The location of the SysV init script directory
618         varies between distributions. If systemd cannot find a native
619         unit file for a requested service, it will look for a SysV
620         init script of the same name (with the
621         <filename>.service</filename> suffix
622         removed).</para></listitem>
623       </varlistentry>
624     </variablelist>
625
626     <variablelist>
627       <varlistentry>
628         <term>SysV runlevel link farm directory</term>
629
630         <listitem><para>The location of the SysV runlevel link farm
631         directory varies between distributions. systemd will take the
632         link farm into account when figuring out whether a service
633         shall be enabled. Note that a service unit with a native unit
634         configuration file cannot be started by activating it in the
635         SysV runlevel link farm.</para></listitem>
636       </varlistentry>
637     </variablelist>
638   </refsect1>
639   // 0 -->
640
641   <!-- 0 /// The whole Signals section is unneeded in elogind
642   <refsect1>
643     <title>Signals</title>
644
645     <variablelist>
646       <varlistentry>
647         <term><constant>SIGTERM</constant></term>
648
649         <listitem><para>Upon receiving this signal the systemd system
650         manager serializes its state, reexecutes itself and
651         deserializes the saved state again. This is mostly equivalent
652         to <command>systemctl daemon-reexec</command>.</para>
653
654         <para>systemd user managers will start the
655         <filename>exit.target</filename> unit when this signal is
656         received. This is mostly equivalent to <command>systemctl
657         &#x2D;&#x2D;user start exit.target
658         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para></listitem>
659       </varlistentry>
660
661       <varlistentry>
662         <term><constant>SIGINT</constant></term>
663
664         <listitem><para>Upon receiving this signal the systemd system
665         manager will start the
666         <filename>ctrl-alt-del.target</filename> unit. This is mostly
667         equivalent to <command>systemctl start ctl-alt-del.target
668         &#x2D;&#x2D;job-mode=replace-irreversible</command>. If this signal is
669         received more than 7 times per 2s, an immediate reboot is
670         triggered.  Note that pressing Ctrl-Alt-Del on the console
671         will trigger this signal. Hence, if a reboot is hanging,
672         pressing Ctrl-Alt-Del more than 7 times in 2s is a relatively
673         safe way to trigger an immediate reboot.</para>
674
675         <para>systemd user managers treat this signal the same way as
676         <constant>SIGTERM</constant>.</para></listitem>
677       </varlistentry>
678
679       <varlistentry>
680         <term><constant>SIGWINCH</constant></term>
681
682         <listitem><para>When this signal is received the systemd
683         system manager will start the
684         <filename>kbrequest.target</filename> unit. This is mostly
685         equivalent to <command>systemctl start
686         kbrequest.target</command>.</para>
687
688         <para>This signal is ignored by systemd user
689         managers.</para></listitem>
690       </varlistentry>
691
692       <varlistentry>
693         <term><constant>SIGPWR</constant></term>
694
695         <listitem><para>When this signal is received the systemd
696         manager will start the <filename>sigpwr.target</filename>
697         unit. This is mostly equivalent to <command>systemctl start
698         sigpwr.target</command>.</para></listitem>
699       </varlistentry>
700
701       <varlistentry>
702         <term><constant>SIGUSR1</constant></term>
703
704         <listitem><para>When this signal is received the systemd
705         manager will try to reconnect to the D-Bus
706         bus.</para></listitem>
707       </varlistentry>
708
709       <varlistentry>
710         <term><constant>SIGUSR2</constant></term>
711
712         <listitem><para>When this signal is received the systemd
713         manager will log its complete state in human-readable form.
714         The data logged is the same as printed by
715         <command>systemd-analyze dump</command>.</para></listitem>
716       </varlistentry>
717
718       <varlistentry>
719         <term><constant>SIGHUP</constant></term>
720
721         <listitem><para>Reloads the complete daemon configuration.
722         This is mostly equivalent to <command>systemctl
723         daemon-reload</command>.</para></listitem>
724       </varlistentry>
725
726       <varlistentry>
727         <term><constant>SIGRTMIN+0</constant></term>
728
729         <listitem><para>Enters default mode, starts the
730         <filename>default.target</filename> unit. This is mostly
731         equivalent to <command>systemctl isolate
732         default.target</command>.</para></listitem>
733       </varlistentry>
734
735       <varlistentry>
736         <term><constant>SIGRTMIN+1</constant></term>
737
738         <listitem><para>Enters rescue mode, starts the
739         <filename>rescue.target</filename> unit. This is mostly
740         equivalent to <command>systemctl isolate
741         rescue.target</command>.</para></listitem>
742       </varlistentry>
743
744       <varlistentry>
745         <term><constant>SIGRTMIN+2</constant></term>
746
747         <listitem><para>Enters emergency mode, starts the
748         <filename>emergency.service</filename> unit. This is mostly
749         equivalent to <command>systemctl isolate
750         emergency.service</command>.</para></listitem>
751       </varlistentry>
752
753       <varlistentry>
754         <term><constant>SIGRTMIN+3</constant></term>
755
756         <listitem><para>Halts the machine, starts the
757         <filename>halt.target</filename> unit. This is mostly
758         equivalent to <command>systemctl start halt.target
759         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
760         </listitem>
761       </varlistentry>
762
763       <varlistentry>
764         <term><constant>SIGRTMIN+4</constant></term>
765
766         <listitem><para>Powers off the machine, starts the
767         <filename>poweroff.target</filename> unit. This is mostly
768         equivalent to <command>systemctl start poweroff.target
769         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
770         </listitem>
771       </varlistentry>
772
773       <varlistentry>
774         <term><constant>SIGRTMIN+5</constant></term>
775
776         <listitem><para>Reboots the machine, starts the
777         <filename>reboot.target</filename> unit. This is mostly
778         equivalent to <command>systemctl start reboot.target
779         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
780         </listitem>
781       </varlistentry>
782
783       <varlistentry>
784         <term><constant>SIGRTMIN+6</constant></term>
785
786         <listitem><para>Reboots the machine via kexec, starts the
787         <filename>kexec.target</filename> unit. This is mostly
788         equivalent to <command>systemctl start kexec.target
789         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
790         </listitem>
791       </varlistentry>
792
793       <varlistentry>
794         <term><constant>SIGRTMIN+13</constant></term>
795
796         <listitem><para>Immediately halts the machine.</para></listitem>
797       </varlistentry>
798
799       <varlistentry>
800         <term><constant>SIGRTMIN+14</constant></term>
801
802         <listitem><para>Immediately powers off the machine.</para></listitem>
803       </varlistentry>
804
805       <varlistentry>
806         <term><constant>SIGRTMIN+15</constant></term>
807
808         <listitem><para>Immediately reboots the machine.</para></listitem>
809       </varlistentry>
810
811       <varlistentry>
812         <term><constant>SIGRTMIN+16</constant></term>
813
814         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
815       </varlistentry>
816
817       <varlistentry>
818         <term><constant>SIGRTMIN+20</constant></term>
819
820         <listitem><para>Enables display of status messages on the
821         console, as controlled via
822         <varname>systemd.show_status=1</varname> on the kernel command
823         line.</para></listitem>
824       </varlistentry>
825
826       <varlistentry>
827         <term><constant>SIGRTMIN+21</constant></term>
828
829         <listitem><para>Disables display of
830         status messages on the console, as
831         controlled via
832         <varname>systemd.show_status=0</varname>
833         on the kernel command
834         line.</para></listitem>
835       </varlistentry>
836
837       <varlistentry>
838         <term><constant>SIGRTMIN+22</constant></term>
839         <term><constant>SIGRTMIN+23</constant></term>
840
841         <listitem><para>Sets the log level to <literal>debug</literal>
842         (or <literal>info</literal> on
843         <constant>SIGRTMIN+23</constant>), as controlled via
844         <varname>systemd.log_level=debug</varname> (or
845         <varname>systemd.log_level=info</varname> on
846         <constant>SIGRTMIN+23</constant>) on the kernel command
847         line.</para></listitem>
848       </varlistentry>
849
850       <varlistentry>
851         <term><constant>SIGRTMIN+24</constant></term>
852
853         <listitem><para>Immediately exits the manager (only available
854         for &#x2D;&#x2D;user instances).</para></listitem>
855       </varlistentry>
856
857       <varlistentry>
858         <term><constant>SIGRTMIN+26</constant></term>
859         <term><constant>SIGRTMIN+27</constant></term>
860         <term><constant>SIGRTMIN+28</constant></term>
861
862         <listitem><para>Sets the log target to
863         <literal>journal-or-kmsg</literal> (or
864         <literal>console</literal> on
865         <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
866         <constant>SIGRTMIN+28</constant>), as controlled via
867         <varname>systemd.log_target=journal-or-kmsg</varname> (or
868         <varname>systemd.log_target=console</varname> on
869         <constant>SIGRTMIN+27</constant> or
870         <varname>systemd.log_target=kmsg</varname> on
871         <constant>SIGRTMIN+28</constant>) on the kernel command
872         line.</para></listitem>
873       </varlistentry>
874     </variablelist>
875   </refsect1>
876   // 0 -->
877
878   <!-- 0 /// The whole environment section is unneeded in elogind 
879   <refsect1>
880     <title>Environment</title>
881
882     <variablelist class='environment-variables'>
883       <varlistentry>
884         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
885         <listitem><para>systemd reads the log level from this
886         environment variable. This can be overridden with
887         <option>&#x2D;&#x2D;log-level=</option>.</para></listitem>
888       </varlistentry>
889
890       <varlistentry>
891         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
892         <listitem><para>systemd reads the log target from this
893         environment variable. This can be overridden with
894         <option>&#x2D;&#x2D;log-target=</option>.</para></listitem>
895       </varlistentry>
896
897       <varlistentry>
898         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
899         <listitem><para>Controls whether systemd highlights important
900         log messages. This can be overridden with
901         <option>&#x2D;&#x2D;log-color=</option>.</para></listitem>
902       </varlistentry>
903
904       <varlistentry>
905         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
906         <listitem><para>Controls whether systemd prints the code
907         location along with log messages. This can be overridden with
908         <option>&#x2D;&#x2D;log-location=</option>.</para></listitem>
909       </varlistentry>
910
911       <varlistentry>
912         <term><varname>$XDG_CONFIG_HOME</varname></term>
913         <term><varname>$XDG_CONFIG_DIRS</varname></term>
914         <term><varname>$XDG_DATA_HOME</varname></term>
915         <term><varname>$XDG_DATA_DIRS</varname></term>
916
917         <listitem><para>The systemd user manager uses these variables
918         in accordance to the <ulink
919         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
920         Base Directory specification</ulink> to find its
921         configuration.</para></listitem>
922       </varlistentry>
923
924       <varlistentry>
925         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
926
927         <listitem><para>Controls where systemd looks for unit
928         files.</para></listitem>
929       </varlistentry>
930
931       <varlistentry>
932         <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
933
934         <listitem><para>Controls where systemd looks for SysV init
935         scripts.</para></listitem>
936       </varlistentry>
937
938       <varlistentry>
939         <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
940
941         <listitem><para>Controls where systemd looks for SysV init
942         script runlevel link farms.</para></listitem>
943       </varlistentry>
944
945       <varlistentry>
946         <term><varname>$SYSTEMD_COLORS</varname></term>
947
948         <listitem><para>The value must be a boolean. Controls whether colorized output should be
949         generated. This can be specified to override the decision that <command>systemd</command>
950         makes based on <varname>$TERM</varname> and what the console is connected to.</para>
951         </listitem>
952       </varlistentry>
953
954       <varlistentry>
955         <term><varname>$LISTEN_PID</varname></term>
956         <term><varname>$LISTEN_FDS</varname></term>
957         <term><varname>$LISTEN_FDNAMES</varname></term>
958
959         <listitem><para>Set by systemd for supervised processes during
960         socket-based activation. See
961         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
962         for more information.</para></listitem>
963       </varlistentry>
964
965       <varlistentry>
966         <term><varname>$NOTIFY_SOCKET</varname></term>
967
968         <listitem><para>Set by systemd for supervised processes for
969         status and start-up completion notification. See
970         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
971         for more information.</para></listitem>
972       </varlistentry>
973     </variablelist>
974   </refsect1>
975   // 0 -->
976
977   <!-- 0 /// The whole kernel section is unneeded in elogind
978   <refsect1>
979     <title>Kernel Command Line</title>
980
981     <para>When run as system instance systemd parses a number of
982     kernel command line arguments<footnote><para>If run inside a Linux
983     container these arguments may be passed as command line arguments
984     to systemd itself, next to any of the command line options listed
985     in the Options section above. If run outside of Linux containers,
986     these arguments are parsed from <filename>/proc/cmdline</filename>
987     instead.</para></footnote>:</para>
988
989     <variablelist class='kernel-commandline-options'>
990       <varlistentry>
991         <term><varname>systemd.unit=</varname></term>
992         <term><varname>rd.systemd.unit=</varname></term>
993
994         <listitem><para>Overrides the unit to activate on boot.
995         Defaults to <filename>default.target</filename>. This may be
996         used to temporarily boot into a different boot unit, for
997         example <filename>rescue.target</filename> or
998         <filename>emergency.service</filename>. See
999         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1000         for details about these units. The option prefixed with
1001         <literal>rd.</literal> is honored only in the initial RAM disk
1002         (initrd), while the one that is not prefixed only in the main
1003         system.</para></listitem>
1004       </varlistentry>
1005
1006       <varlistentry>
1007         <term><varname>systemd.dump_core</varname></term>
1008
1009         <listitem><para>Takes a boolean argument or enables the option if specified
1010         without an argument. If enabled, the systemd manager (PID 1) dumps core when
1011         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
1012         </listitem>
1013       </varlistentry>
1014
1015       <varlistentry>
1016         <term><varname>systemd.crash_chvt</varname></term>
1017
1018         <listitem><para>Takes a positive integer, or a boolean argument. Can be also
1019         specified without an argument, with the same effect as a positive boolean. If
1020         a positive integer (in the range 1–63) is specified, the system manager (PID
1021         1) will activate the specified virtual terminal (VT) when it
1022         crashes. Defaults to disabled, meaning that no such switch is attempted. If
1023         set to enabled, the VT the kernel messages are written to is selected.
1024         </para></listitem>
1025       </varlistentry>
1026
1027       <varlistentry>
1028         <term><varname>systemd.crash_shell</varname></term>
1029
1030         <listitem><para>Takes a boolean argument or enables the option if specified
1031         without an argument. If enabled, the system manager (PID 1) spawns a shell
1032         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
1033         to disabled, for security reasons, as the shell is not protected by password
1034         authentication.</para></listitem>
1035       </varlistentry>
1036
1037       <varlistentry>
1038         <term><varname>systemd.crash_reboot</varname></term>
1039
1040         <listitem><para>Takes a boolean argument or enables the option if specified
1041         without an argument. If enabled, the system manager (PID 1) will reboot the
1042         machine automatically when it crashes, after a 10s delay.  Otherwise, the
1043         system will hang indefinitely. Defaults to disabled, in order to avoid a
1044         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
1045         system is rebooted after the shell exits.</para></listitem>
1046       </varlistentry>
1047
1048       <varlistentry>
1049         <term><varname>systemd.confirm_spawn</varname></term>
1050
1051         <listitem><para>Takes a boolean argument or a path to the virtual console
1052         where the confirmation messages should be emitted. Can be also specified
1053         without an argument, with the same effect as a positive boolean. If enabled,
1054         the system manager (PID 1) asks for confirmation when spawning processes
1055         using <option>/dev/console</option>. If a path or a console name (such as
1056         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
1057         path or described by the give name will be used instead. Defaults to disabled.
1058         </para></listitem>
1059       </varlistentry>
1060
1061       <varlistentry>
1062         <term><varname>systemd.show_status</varname></term>
1063
1064         <listitem><para>Takes a boolean argument or the constant
1065         <constant>auto</constant>. Can be also specified without an argument, with
1066         the same effect as a positive boolean.  If enabled, the systemd manager (PID
1067         1) shows terse service status updates on the console during bootup.
1068         <constant>auto</constant> behaves like <option>false</option> until a unit
1069         fails or there is a significant delay in boot. Defaults to enabled, unless
1070         <option>quiet</option> is passed as kernel command line option, in which case
1071         it defaults to <constant>auto</constant>. If specified overrides the system
1072         manager configuration file option <option>ShowStatus=</option>, see
1073         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
1074         However, the process command line option <option>&#x2D;&#x2D;show-status=</option>
1075         takes precedence over both this kernel command line option and the
1076         configuration file option.</para></listitem>
1077       </varlistentry>
1078
1079       <varlistentry>
1080         <term><varname>systemd.log_target=</varname></term>
1081         <term><varname>systemd.log_level=</varname></term>
1082         <term><varname>systemd.log_location=</varname></term>
1083         <term><varname>systemd.log_color</varname></term>
1084
1085         <listitem><para>Controls log output, with the same effect as the
1086         <varname>$SYSTEMD_LOG_TARGET</varname>,
1087         <varname>$SYSTEMD_LOG_LEVEL</varname>,
1088         <varname>$SYSTEMD_LOG_LOCATION</varname>,
1089         <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above.
1090         <varname>systemd.log_color</varname> can be specified without an argument,
1091         with the same effect as a positive boolean.</para></listitem>
1092       </varlistentry>
1093
1094       <varlistentry>
1095         <term><varname>systemd.default_standard_output=</varname></term>
1096         <term><varname>systemd.default_standard_error=</varname></term>
1097         <listitem><para>Controls default standard output and error
1098         output for services, with the same effect as the
1099         <option>&#x2D;&#x2D;default-standard-output=</option> and
1100         <option>&#x2D;&#x2D;default-standard-error=</option> command line
1101         arguments described above, respectively.</para></listitem>
1102       </varlistentry>
1103
1104       <varlistentry>
1105         <term><varname>systemd.setenv=</varname></term>
1106
1107         <listitem><para>Takes a string argument in the form
1108         VARIABLE=VALUE. May be used to set default environment
1109         variables to add to forked child processes. May be used more
1110         than once to set multiple variables.</para></listitem>
1111       </varlistentry>
1112
1113       <varlistentry>
1114         <term><varname>systemd.machine_id=</varname></term>
1115
1116         <listitem><para>Takes a 32 character hex value to be
1117         used for setting the machine-id. Intended mostly for
1118         network booting where the same machine-id is desired
1119         for every boot.</para></listitem>
1120       </varlistentry>
1121
1122       <varlistentry>
1123         <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
1124
1125         <listitem><para>When specified without an argument or with a true argument,
1126         enables the usage of
1127         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">unified cgroup hierarchy</ulink>
1128         (a.k.a. cgroups-v2). When specified with a false argument, fall back to
1129         hybrid or full legacy cgroup hierarchy.</para>
1130
1131         <para>If this option is not specified, the default behaviour is determined
1132         during compilation (the <option>&#x2D;&#x2D;with-default-hierarchy=</option>
1133         option). If the kernel does not support unified cgroup hierarchy, the legacy
1134         hierarchy will be used even if this option is specified.</para>
1135         </listitem>
1136       </varlistentry>
1137
1138       <varlistentry>
1139         <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
1140
1141         <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
1142         (see previous option). When specified without an argument or with a true
1143         argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
1144         tree used for systemd, and
1145         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
1146         cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
1147         forces a full "legacy" mode. When specified with a false argument, enables
1148         the use of "hybrid" hierarchy.</para>
1149
1150         <para>If this option is not specified, the default behaviour is determined
1151         during compilation (the <option>&#x2D;&#x2D;with-default-hierarchy=</option>
1152         option). If the kernel does not support unified cgroup hierarchy, the legacy
1153         hierarchy will be used  even if this option is specified.</para>
1154         </listitem>
1155       </varlistentry>
1156
1157       <varlistentry>
1158         <term><varname>quiet</varname></term>
1159
1160         <listitem><para>Turn off status output at boot, much like
1161         <varname>systemd.show_status=false</varname> would. Note that
1162         this option is also read by the kernel itself and disables
1163         kernel log output. Passing this option hence turns off the
1164         usual output from both the system manager and the kernel.
1165         </para></listitem>
1166       </varlistentry>
1167
1168       <varlistentry>
1169         <term><varname>debug</varname></term>
1170
1171         <listitem><para>Turn on debugging output. This is equivalent
1172         to <varname>systemd.log_level=debug</varname>. Note that this
1173         option is also read by the kernel itself and enables kernel
1174         debug output. Passing this option hence turns on the debug
1175         output from both the system manager and the
1176         kernel.</para></listitem>
1177       </varlistentry>
1178
1179       <varlistentry>
1180         <term><varname>emergency</varname></term>
1181         <term><varname>rd.emergency</varname></term>
1182         <term><varname>-b</varname></term>
1183
1184         <listitem><para>Boot into emergency mode. This is equivalent
1185         to <varname>systemd.unit=emergency.target</varname> or
1186         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1187         provided for compatibility reasons and to be easier to type.</para></listitem>
1188       </varlistentry>
1189
1190       <varlistentry>
1191         <term><varname>rescue</varname></term>
1192         <term><varname>rd.rescue</varname></term>
1193         <term><varname>single</varname></term>
1194         <term><varname>s</varname></term>
1195         <term><varname>S</varname></term>
1196         <term><varname>1</varname></term>
1197
1198         <listitem><para>Boot into rescue mode. This is equivalent to
1199         <varname>systemd.unit=rescue.target</varname> or
1200         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1201         provided for compatibility reasons and to be easier to type.</para></listitem>
1202       </varlistentry>
1203
1204       <varlistentry>
1205         <term><varname>2</varname></term>
1206         <term><varname>3</varname></term>
1207         <term><varname>4</varname></term>
1208         <term><varname>5</varname></term>
1209
1210         <listitem><para>Boot into the specified legacy SysV runlevel.
1211         These are equivalent to
1212         <varname>systemd.unit=runlevel2.target</varname>,
1213         <varname>systemd.unit=runlevel3.target</varname>,
1214         <varname>systemd.unit=runlevel4.target</varname>, and
1215         <varname>systemd.unit=runlevel5.target</varname>,
1216         respectively, and provided for compatibility reasons and to be
1217         easier to type.</para></listitem>
1218       </varlistentry>
1219
1220       <varlistentry>
1221         <term><varname>locale.LANG=</varname></term>
1222         <term><varname>locale.LANGUAGE=</varname></term>
1223         <term><varname>locale.LC_CTYPE=</varname></term>
1224         <term><varname>locale.LC_NUMERIC=</varname></term>
1225         <term><varname>locale.LC_TIME=</varname></term>
1226         <term><varname>locale.LC_COLLATE=</varname></term>
1227         <term><varname>locale.LC_MONETARY=</varname></term>
1228         <term><varname>locale.LC_MESSAGES=</varname></term>
1229         <term><varname>locale.LC_PAPER=</varname></term>
1230         <term><varname>locale.LC_NAME=</varname></term>
1231         <term><varname>locale.LC_ADDRESS=</varname></term>
1232         <term><varname>locale.LC_TELEPHONE=</varname></term>
1233         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1234         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1235
1236         <listitem><para>Set the system locale to use. This overrides
1237         the settings in <filename>/etc/locale.conf</filename>. For
1238         more information, see
1239         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1240         and
1241         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1242         </para></listitem>
1243       </varlistentry>
1244     </variablelist>
1245
1246     <para>For other kernel command line parameters understood by
1247     components of the core OS, please refer to
1248     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1249   </refsect1>
1250   // 0 -->
1251
1252   <!-- 0 /// The whole sockets section is unneeded in elogind
1253   <refsect1>
1254     <title>Sockets and FIFOs</title>
1255
1256     <variablelist>
1257       <varlistentry>
1258         <term><filename>/run/systemd/notify</filename></term>
1259
1260         <listitem><para>Daemon status notification socket. This is an
1261         <constant>AF_UNIX</constant> datagram socket and is used to
1262         implement the daemon notification logic as implemented by
1263         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1264
1265       </varlistentry>
1266
1267       <varlistentry>
1268         <term><filename>/run/systemd/private</filename></term>
1269
1270         <listitem><para>Used internally as communication channel
1271         between
1272         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1273         and the systemd process. This is an
1274         <constant>AF_UNIX</constant> stream socket. This interface is
1275         private to systemd and should not be used in external
1276         projects.</para></listitem>
1277       </varlistentry>
1278
1279       <varlistentry>
1280         <term><filename>/dev/initctl</filename></term>
1281
1282         <listitem><para>Limited compatibility support for the SysV
1283         client interface, as implemented by the
1284         <filename>systemd-initctl.service</filename> unit. This is a
1285         named pipe in the file system. This interface is obsolete and
1286         should not be used in new applications.</para></listitem>
1287       </varlistentry>
1288     </variablelist>
1289   </refsect1>
1290   // 0 -->
1291
1292   <refsect1>
1293     <title>See Also</title>
1294     <para>
1295       <!-- 0 /// elogind does not have that much to see also...
1296       The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1297       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1298       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1299       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1300       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1301       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1302       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1303       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1304       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1305       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1306       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1307       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1308       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1309       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1310       else -->
1311       The <ulink url="https://github.com/elogind/elogind/">elogind Homepage</ulink>,
1312       <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1313       <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1314       <citerefentry><refentrytitle>pam_elogind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1315       <!-- // 0 -->
1316     </para>
1317   </refsect1>
1318
1319 </refentry>