]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.xml
man: update the list of unit search locations
[thirdparty/systemd.git] / man / systemd.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
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 This file is part of systemd.
7
8 Copyright 2010 Lennart Poettering
9
10 systemd is free software; you can redistribute it and/or modify it
11 under the terms of the GNU General Public License as published by
12 the Free Software Foundation; either version 2 of the License, or
13 (at your option) any later version.
14
15 systemd is distributed in the hope that it will be useful, but
16 WITHOUT ANY WARRANTY; without even the implied warranty of
17 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
18 General Public License for more details.
19
20 You should have received a copy of the GNU General Public License
21 along with systemd; If not, see <http://www.gnu.org/licenses/>.
22 -->
23
24 <refentry id="systemd">
25
26 <refentryinfo>
27 <title>systemd</title>
28 <productname>systemd</productname>
29
30 <authorgroup>
31 <author>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
36 </author>
37 </authorgroup>
38 </refentryinfo>
39
40 <refmeta>
41 <refentrytitle>systemd</refentrytitle>
42 <manvolnum>1</manvolnum>
43 </refmeta>
44
45 <refnamediv>
46 <refname>systemd</refname>
47 <refname>init</refname>
48 <refpurpose>systemd System and Service Manager</refpurpose>
49 </refnamediv>
50
51 <refsynopsisdiv>
52 <cmdsynopsis>
53 <command>systemd <arg choice="opt" rep="repeat">OPTIONS</arg></command>
54 </cmdsynopsis>
55 <cmdsynopsis>
56 <command>init <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
57 </cmdsynopsis>
58 </refsynopsisdiv>
59
60 <refsect1>
61 <title>Description</title>
62
63 <para>systemd is a system and service manager for
64 Linux operating systems. When run as first process on
65 boot (as PID 1), it acts as init system that brings
66 up and maintains userspace services.</para>
67
68 <para>For compatibility with SysV, if systemd is called
69 as <command>init</command> and a PID that is not
70 1, it will execute <command>telinit</command> and pass
71 all command line arguments unmodified. That means
72 <command>init</command> and <command>telinit</command>
73 are mostly equivalent when invoked from normal login sessions. See
74 <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
75 for more information.</para>
76
77 <para>When run as system instance, systemd interprets
78 the configuration file
79 <filename>system.conf</filename>, otherwise
80 <filename>user.conf</filename>. See
81 <citerefentry><refentrytitle>systemd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
82 for more information.</para>
83 </refsect1>
84
85 <refsect1>
86 <title>Options</title>
87
88 <para>The following options are understood:</para>
89
90 <variablelist>
91 <varlistentry>
92 <term><option>-h</option></term>
93 <term><option>--help</option></term>
94
95 <listitem><para>Prints a short help
96 text and exits.</para></listitem>
97 </varlistentry>
98 <varlistentry>
99 <term><option>--test</option></term>
100
101 <listitem><para>Determine startup
102 sequence, dump it and exit. This is an
103 option useful for debugging
104 only.</para></listitem>
105 </varlistentry>
106 <varlistentry>
107 <term><option>--dump-configuration-items</option></term>
108
109 <listitem><para>Dump understood unit
110 configuration items. This outputs a
111 terse but complete list of
112 configuration items understood in unit
113 definition files.</para></listitem>
114 </varlistentry>
115 <varlistentry>
116 <term><option>--introspect=</option></term>
117
118 <listitem><para>Extract D-Bus
119 interface introspection data. This is
120 mostly useful at install time
121 to generate data suitable for the
122 D-Bus interfaces
123 repository. Optionally the interface
124 name for the introspection data may be
125 specified. If omitted, the
126 introspection data for all interfaces
127 is dumped.</para></listitem>
128 </varlistentry>
129 <varlistentry>
130 <term><option>--unit=</option></term>
131
132 <listitem><para>Set default unit to
133 activate on startup. If not specified
134 defaults to
135 <filename>default.target</filename>.</para></listitem>
136 </varlistentry>
137 <varlistentry>
138 <term><option>--system</option></term>
139 <term><option>--user</option></term>
140
141 <listitem><para>Tell systemd to run a
142 system instance (resp. user
143 instance), even if the process ID is
144 not 1 (resp. is 1), i.e. systemd is
145 not (resp. is) run as init process.
146 Normally it should not be necessary to
147 pass these options, as systemd
148 automatically detects the mode it is
149 started in. These options are hence of
150 little use except for debugging. Note
151 that it is not supported booting and
152 maintaining a full system with systemd
153 running in <option>--system</option>
154 mode, but PID not 1. In practice,
155 passing <option>--system</option> explicitly is
156 only useful in conjunction with
157 <option>--test</option>.</para></listitem>
158 </varlistentry>
159 <varlistentry>
160 <term><option>--dump-core</option></term>
161
162 <listitem><para>Dump core on
163 crash. This switch has no effect when
164 run as user
165 instance.</para></listitem>
166 </varlistentry>
167 <varlistentry>
168 <term><option>--crash-shell</option></term>
169
170 <listitem><para>Run shell on
171 crash. This switch has no effect when
172 run as user
173 instance.</para></listitem>
174 </varlistentry>
175 <varlistentry>
176 <term><option>--confirm-spawn</option></term>
177
178 <listitem><para>Ask for confirmation
179 when spawning processes. This switch
180 has no effect when run as user
181 instance.</para></listitem>
182 </varlistentry>
183 <varlistentry>
184 <term><option>--show-status=</option></term>
185
186 <listitem><para>Show terse service
187 status information while booting. This
188 switch has no effect when run as user
189 instance. Takes a boolean argument
190 which may be omitted which is
191 interpreted as
192 <option>true</option>.</para></listitem>
193 </varlistentry>
194 <varlistentry>
195 <term><option>--sysv-console=</option></term>
196
197 <listitem><para>Controls whether
198 output of SysV init scripts will be
199 directed to the console. This switch
200 has no effect when run as user
201 instance. Takes a boolean argument
202 which may be omitted which is
203 interpreted as
204 <option>true</option>.</para></listitem>
205 </varlistentry>
206 <varlistentry>
207 <term><option>--log-target=</option></term>
208
209 <listitem><para>Set log
210 target. Argument must be one of
211 <option>console</option>,
212 <option>syslog</option>,
213 <option>kmsg</option>,
214 <option>syslog-or-kmsg</option>,
215 <option>null</option>.</para></listitem>
216 </varlistentry>
217 <varlistentry>
218 <term><option>--log-level=</option></term>
219
220 <listitem><para>Set log level. As
221 argument this accepts a numerical log
222 level or the well-known <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
223 symbolic names (lowercase):
224 <option>emerg</option>,
225 <option>alert</option>,
226 <option>crit</option>,
227 <option>err</option>,
228 <option>warning</option>,
229 <option>notice</option>,
230 <option>info</option>,
231 <option>debug</option>.</para></listitem>
232 </varlistentry>
233 <varlistentry>
234 <term><option>--log-color=</option></term>
235
236 <listitem><para>Highlight important
237 log messages. Argument is a boolean
238 value. If the argument is omitted it
239 defaults to
240 <option>true</option>.</para></listitem>
241 </varlistentry>
242 <varlistentry>
243 <term><option>--log-location=</option></term>
244
245 <listitem><para>Include code location
246 in log messages. This is mostly
247 relevant for debugging
248 purposes. Argument is a boolean
249 value. If the argument is omitted
250 it defaults to
251 <option>true</option>.</para></listitem>
252 </varlistentry>
253 <varlistentry>
254 <term><option>--default-standard-output=</option></term>
255 <term><option>--default-standard-error=</option></term>
256
257 <listitem><para>Sets the default
258 output resp. error output for all
259 services and sockets, i.e. controls
260 the default for
261 <option>StandardOutput=</option>
262 resp. <option>StandardExecute=</option>
263 (see
264 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
265 for details). Takes one of
266 <option>inherit</option>,
267 <option>null</option>,
268 <option>tty</option>,
269 <option>syslog</option>,
270 <option>syslog+console</option>,
271 <option>kmsg</option>,
272 <option>kmsg+console</option>. If the
273 argument is omitted it defaults to
274 <option>inherit</option>.</para></listitem>
275 </varlistentry>
276 </variablelist>
277 </refsect1>
278
279 <refsect1>
280 <title>Concepts</title>
281
282 <para>systemd provides a dependency system between
283 various entities called "units". Units encapsulate
284 various objects that are relevant for system boot-up
285 and maintenance. The majority of units are configured
286 in unit configuration files, whose syntax and basic
287 set of options is described in
288 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
289 however some are created automatically from other
290 configuration or dynamically from system state. Units
291 may be 'active' (meaning started, bound, plugged in,
292 ... depending on the unit type, see below), or
293 'inactive' (meaning stopped, unbound, unplugged, ...),
294 as well as in the process of being activated or
295 deactivated, i.e. between the two states (these states
296 are called 'activating', 'deactivating'). A special
297 'failed' state is available as well which is very
298 similar to 'inactive' and is entered when the service
299 failed in some way (process returned error code on
300 exit, or crashed, or an operation timed out). If this
301 state is entered the cause will be logged, for later
302 reference. Note that the various unit types may have a
303 number of additional substates, which are mapped to
304 the five generalized unit states described
305 here.</para>
306
307 <para>The following unit types are available:</para>
308
309 <orderedlist>
310 <listitem><para>Service units, which control
311 daemons and the processes they consist of. For
312 details see
313 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
314
315 <listitem><para>Socket units, which
316 encapsulate local IPC or network sockets in
317 the system, useful for socket-based
318 activation. For details about socket units see
319 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
320 for details on socket-based activation and
321 other forms of activation, see
322 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
323
324 <listitem><para>Target units are useful to
325 group units, or provide well-known
326 synchronization points during boot-up, see
327 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
328
329 <listitem><para>Device units expose kernel
330 devices in systemd and may be used to
331 implement device-based activation. For details
332 see
333 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
334
335 <listitem><para>Mount units control mount
336 points in the file system, for details see
337 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
338
339 <listitem><para>Automount units provide
340 automount capabilities, for on-demand mounting
341 of file systems as well as parallelized
342 boot-up. See
343 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
344
345 <listitem><para>Snapshot units can be used to
346 temporarily save the state of the set of
347 systemd units, which later may be restored by
348 activating the saved snapshot unit. For more
349 information see
350 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
351
352 <listitem><para>Timer units are useful for
353 triggering activation of other units based on
354 timers. You may find details in
355 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
356
357 <listitem><para>Swap units are very similar to
358 mount units and encapsulate memory swap
359 partitions or files of the operating
360 system. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
361
362 <listitem><para>Path units may be used
363 to activate other services when file system
364 objects change or are modified. See
365 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
366
367 </orderedlist>
368
369 <para>Units are named as their configuration
370 files. Some units have special semantics. A detailed
371 list is available in
372 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
373
374 <para>systemd knows various kinds of dependencies,
375 including positive and negative requirement
376 dependencies (i.e. <varname>Requires=</varname> and
377 <varname>Conflicts=</varname>) as well as ordering
378 dependencies (<varname>After=</varname> and
379 <varname>Before=</varname>). NB: ordering and
380 requirement dependencies are orthogonal. If only a
381 requirement dependency exists between two units
382 (e.g. <filename>foo.service</filename> requires
383 <filename>bar.service</filename>), but no ordering
384 dependency (e.g. <filename>foo.service</filename>
385 after <filename>bar.service</filename>) and both are
386 requested to start, they will be started in
387 parallel. It is a common pattern that both requirement
388 and ordering dependencies are placed between two
389 units. Also note that the majority of dependencies are
390 implicitly created and maintained by systemd. In most
391 cases it should be unnecessary to declare additional
392 dependencies manually, however it is possible to do
393 this.</para>
394
395 <para>Application programs and units (via
396 dependencies) may request state changes of units. In
397 systemd, these requests are encapsulated as 'jobs' and
398 maintained in a job queue. Jobs may succeed or can
399 fail, their execution is ordered based on the ordering
400 dependencies of the units they have been scheduled
401 for.</para>
402
403 <para>On boot systemd activates the target unit
404 <filename>default.target</filename> whose job is to
405 activate on-boot services and other on-boot units by
406 pulling them in via dependencies. Usually the unit
407 name is just an alias (symlink) for either
408 <filename>graphical.target</filename> (for
409 fully-featured boots into the UI) or
410 <filename>multi-user.target</filename> (for limited
411 console-only boots for use in embedded or server
412 environments, or similar; a subset of
413 graphical.target). However it is at the discretion of
414 the administrator to configure it as an alias to any
415 other target unit. See
416 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
417 for details about these target units.</para>
418
419 <para>Processes systemd spawns are placed in
420 individual Linux control groups named after the unit
421 which they belong to in the private systemd
422 hierarchy. (see <ulink
423 url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
424 for more information about control groups, or short
425 "cgroups"). systemd uses this to effectively keep
426 track of processes. Control group information is
427 maintained in the kernel, and is accessible via the
428 file system hierarchy (beneath
429 <filename>/sys/fs/cgroup/systemd/</filename>), or in tools
430 such as
431 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
432 (<command>ps xawf -eo pid,user,cgroup,args</command>
433 is particularly useful to list all processes and the
434 systemd units they belong to.).</para>
435
436 <para>systemd is compatible with the SysV init system
437 to a large degree: SysV init scripts are supported and
438 simply read as an alternative (though limited)
439 configuration file format. The SysV
440 <filename>/dev/initctl</filename> interface is
441 provided, and compatibility implementations of the
442 various SysV client tools are available. In addition to
443 that, various established Unix functionality such as
444 <filename>/etc/fstab</filename> or the
445 <filename>utmp</filename> database are
446 supported.</para>
447
448 <para>systemd has a minimal transaction system: if a
449 unit is requested to start up or shut down it will add
450 it and all its dependencies to a temporary
451 transaction. Then, it will verify if the transaction
452 is consistent (i.e. whether the ordering of all units
453 is cycle-free). If it is not, systemd will try to fix
454 it up, and removes non-essential jobs from the
455 transaction that might remove the loop. Also, systemd
456 tries to suppress non-essential jobs in the
457 transaction that would stop a running service. Finally
458 it is checked whether the jobs of the transaction
459 contradict jobs that have already been queued, and
460 optionally the transaction is aborted then. If all
461 worked out and the transaction is consistent and
462 minimized in its impact it is merged with all already
463 outstanding jobs and added to the run
464 queue. Effectively this means that before executing a
465 requested operation, systemd will verify that it makes
466 sense, fixing it if possible, and only failing if it
467 really cannot work.</para>
468
469 <para>Systemd contains native implementations of
470 various tasks that need to be executed as part of the
471 boot process. For example, it sets the host name or
472 configures the loopback network device. It also sets
473 up and mounts various API file systems, such as
474 <filename>/sys</filename> or
475 <filename>/proc</filename>.</para>
476
477 <para>For more information about the concepts and
478 ideas behind systemd please refer to the <ulink
479 url="http://0pointer.de/blog/projects/systemd.html">Original
480 Design Document</ulink>.</para>
481
482 <para>Note that some but not all interfaces provided
483 by systemd are covered by the <ulink
484 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
485 Stability Promise</ulink>.</para>
486 </refsect1>
487
488 <refsect1>
489 <title>Directories</title>
490
491 <variablelist>
492 <varlistentry>
493 <term>System unit directories</term>
494
495 <listitem><para>The systemd system
496 manager reads unit configuration from
497 various directories. Packages that
498 want to install unit files shall place
499 them in the directory returned by
500 <command>pkg-config systemd
501 --variable=systemdsystemunitdir</command>. Other
502 directories checked are
503 <filename>/usr/local/lib/systemd/system</filename>
504 and
505 <filename>/usr/lib/systemd/system</filename>. User
506 configuration always takes
507 precedence. <command>pkg-config
508 systemd
509 --variable=systemdsystemconfdir</command>
510 returns the path of the system
511 configuration directory. Packages
512 should alter the content of these
513 directories only with the
514 <command>enable</command> and
515 <command>disable</command> commands of
516 the
517 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
518 tool.</para></listitem>
519 </varlistentry>
520 </variablelist>
521
522 <variablelist>
523 <varlistentry>
524 <term>User unit directories</term>
525
526 <listitem><para>Similar rules apply
527 for the user unit
528 directories. However, here the <ulink
529 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
530 Base Directory specification</ulink>
531 is followed to find
532 units. Applications should place their
533 unit files in the directory returned
534 by <command>pkg-config systemd
535 --variable=systemduserunitdir</command>. Global
536 configuration is done in the directory
537 reported by <command>pkg-config
538 systemd
539 --variable=systemduserconfdir</command>. The
540 <command>enable</command> and
541 <command>disable</command> commands of
542 the
543 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
544 tool can handle both global (i.e. for
545 all users) and private (for one user)
546 enabling/disabling of
547 units.</para></listitem>
548 </varlistentry>
549 </variablelist>
550
551 <variablelist>
552 <varlistentry>
553 <term>SysV init scripts directory</term>
554
555 <listitem><para>The location of the
556 SysV init script directory varies
557 between distributions. If systemd
558 cannot find a native unit file for a
559 requested service, it will look for a
560 SysV init script of the same name
561 (with the
562 <filename>.service</filename> suffix
563 removed).</para></listitem>
564 </varlistentry>
565 </variablelist>
566
567 <variablelist>
568 <varlistentry>
569 <term>SysV runlevel link farm directory</term>
570
571 <listitem><para>The location of the
572 SysV runlevel link farm directory
573 varies between distributions. systemd
574 will take the link farm into account
575 when figuring out whether a service
576 shall be enabled. Note that a service
577 unit with a native unit configuration
578 file cannot be started by activating it
579 in the SysV runlevel link
580 farm.</para></listitem>
581 </varlistentry>
582 </variablelist>
583 </refsect1>
584
585 <refsect1>
586 <title>Signals</title>
587
588 <variablelist>
589 <varlistentry>
590 <term>SIGTERM</term>
591
592 <listitem><para>Upon receiving this
593 signal the systemd system manager
594 serializes its state, reexecutes
595 itself and deserializes the saved
596 state again. This is mostly equivalent
597 to <command>systemctl
598 daemon-reexec</command>.</para>
599
600 <para>systemd user managers will
601 start the
602 <filename>exit.target</filename> unit
603 when this signal is received. This is
604 mostly equivalent to
605 <command>systemctl --user start
606 exit.target</command>.</para></listitem>
607 </varlistentry>
608
609 <varlistentry>
610 <term>SIGINT</term>
611
612 <listitem><para>Upon receiving this
613 signal the systemd system manager will
614 start the
615 <filename>ctrl-alt-del.target</filename> unit. This
616 is mostly equivalent to
617 <command>systemctl start
618 ctl-alt-del.target</command>.</para>
619
620 <para>systemd user managers
621 treat this signal the same way as
622 SIGTERM.</para></listitem>
623 </varlistentry>
624
625 <varlistentry>
626 <term>SIGWINCH</term>
627
628 <listitem><para>When this signal is
629 received the systemd system manager
630 will start the
631 <filename>kbrequest.target</filename>
632 unit. This is mostly equivalent to
633 <command>systemctl start
634 kbrequest.target</command>.</para>
635
636 <para>This signal is ignored by
637 systemd user
638 managers.</para></listitem>
639 </varlistentry>
640
641 <varlistentry>
642 <term>SIGPWR</term>
643
644 <listitem><para>When this signal is
645 received the systemd manager
646 will start the
647 <filename>sigpwr.target</filename>
648 unit. This is mostly equivalent to
649 <command>systemctl start
650 sigpwr.target</command>.</para></listitem>
651 </varlistentry>
652
653 <varlistentry>
654 <term>SIGUSR1</term>
655
656 <listitem><para>When this signal is
657 received the systemd manager will try
658 to reconnect to the D-Bus
659 bus.</para></listitem>
660 </varlistentry>
661
662 <varlistentry>
663 <term>SIGUSR2</term>
664
665 <listitem><para>When this signal is
666 received the systemd manager will log
667 its complete state in human readable
668 form. The data logged is the same as
669 printed by <command>systemctl
670 dump</command>.</para></listitem>
671 </varlistentry>
672
673 <varlistentry>
674 <term>SIGHUP</term>
675
676 <listitem><para>Reloads the complete
677 daemon configuration. This is mostly
678 equivalent to <command>systemctl
679 daemon-reload</command>.</para></listitem>
680 </varlistentry>
681
682 <varlistentry>
683 <term>SIGRTMIN+0</term>
684
685 <listitem><para>Enters default mode, starts the
686 <filename>default.target</filename>
687 unit. This is mostly equivalent to
688 <command>systemctl start
689 default.target</command>.</para></listitem>
690 </varlistentry>
691
692 <varlistentry>
693 <term>SIGRTMIN+1</term>
694
695 <listitem><para>Enters rescue mode,
696 starts the
697 <filename>rescue.target</filename>
698 unit. This is mostly equivalent to
699 <command>systemctl isolate
700 rescue.target</command>.</para></listitem>
701 </varlistentry>
702
703 <varlistentry>
704 <term>SIGRTMIN+2</term>
705
706 <listitem><para>Enters emergency mode,
707 starts the
708 <filename>emergency.service</filename>
709 unit. This is mostly equivalent to
710 <command>systemctl isolate
711 emergency.service</command>.</para></listitem>
712 </varlistentry>
713
714 <varlistentry>
715 <term>SIGRTMIN+3</term>
716
717 <listitem><para>Halts the machine,
718 starts the
719 <filename>halt.target</filename>
720 unit. This is mostly equivalent to
721 <command>systemctl start
722 halt.target</command>.</para></listitem>
723 </varlistentry>
724
725 <varlistentry>
726 <term>SIGRTMIN+4</term>
727
728 <listitem><para>Powers off the machine,
729 starts the
730 <filename>poweroff.target</filename>
731 unit. This is mostly equivalent to
732 <command>systemctl start
733 poweroff.target</command>.</para></listitem>
734 </varlistentry>
735
736 <varlistentry>
737 <term>SIGRTMIN+5</term>
738
739 <listitem><para>Reboots the machine,
740 starts the
741 <filename>reboot.target</filename>
742 unit. This is mostly equivalent to
743 <command>systemctl start
744 reboot.target</command>.</para></listitem>
745 </varlistentry>
746
747 <varlistentry>
748 <term>SIGRTMIN+6</term>
749
750 <listitem><para>Reboots the machine via kexec,
751 starts the
752 <filename>kexec.target</filename>
753 unit. This is mostly equivalent to
754 <command>systemctl start
755 kexec.target</command>.</para></listitem>
756 </varlistentry>
757
758 <varlistentry>
759 <term>SIGRTMIN+13</term>
760
761 <listitem><para>Immediately halts the machine.</para></listitem>
762 </varlistentry>
763
764 <varlistentry>
765 <term>SIGRTMIN+14</term>
766
767 <listitem><para>Immediately powers off the machine.</para></listitem>
768 </varlistentry>
769
770 <varlistentry>
771 <term>SIGRTMIN+15</term>
772
773 <listitem><para>Immediately reboots the machine.</para></listitem>
774 </varlistentry>
775
776 <varlistentry>
777 <term>SIGRTMIN+16</term>
778
779 <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
780 </varlistentry>
781
782 <varlistentry>
783 <term>SIGRTMIN+20</term>
784
785 <listitem><para>Enables display of
786 status messages on the console, as
787 controlled via
788 <varname>systemd.show_status=1</varname>
789 on the kernel command
790 line.</para></listitem>
791 </varlistentry>
792
793 <varlistentry>
794 <term>SIGRTMIN+21</term>
795
796 <listitem><para>Disables display of
797 status messages on the console, as
798 controlled via
799 <varname>systemd.show_status=0</varname>
800 on the kernel command
801 line.</para></listitem>
802 </varlistentry>
803 </variablelist>
804 </refsect1>
805
806 <refsect1>
807 <title>Environment</title>
808
809 <variablelist>
810 <varlistentry>
811 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
812 <listitem><para>systemd reads the
813 log level from this environment
814 variable. This can be overridden with
815 <option>--log-level=</option>.</para></listitem>
816 </varlistentry>
817
818 <varlistentry>
819 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
820 <listitem><para>systemd reads the
821 log target from this environment
822 variable. This can be overridden with
823 <option>--log-target=</option>.</para></listitem>
824 </varlistentry>
825
826 <varlistentry>
827 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
828 <listitem><para>Controls whether
829 systemd highlights important log
830 messages. This can be overridden with
831 <option>--log-color=</option>.</para></listitem>
832 </varlistentry>
833
834 <varlistentry>
835 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
836 <listitem><para>Controls whether
837 systemd prints the code location along
838 with log messages. This can be
839 overridden with
840 <option>--log-location=</option>.</para></listitem>
841 </varlistentry>
842
843 <varlistentry>
844 <term><varname>$XDG_CONFIG_HOME</varname></term>
845 <term><varname>$XDG_CONFIG_DIRS</varname></term>
846 <term><varname>$XDG_DATA_HOME</varname></term>
847 <term><varname>$XDG_DATA_DIRS</varname></term>
848
849 <listitem><para>The systemd user
850 manager uses these variables in
851 accordance to the <ulink
852 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
853 Base Directory specification</ulink>
854 to find its configuration.</para></listitem>
855 </varlistentry>
856
857 <varlistentry>
858 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
859
860 <listitem><para>Controls where systemd
861 looks for unit
862 files.</para></listitem>
863 </varlistentry>
864
865 <varlistentry>
866 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
867
868 <listitem><para>Controls where systemd
869 looks for SysV init scripts.</para></listitem>
870 </varlistentry>
871
872 <varlistentry>
873 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
874
875 <listitem><para>Controls where systemd
876 looks for SysV init script runlevel link
877 farms.</para></listitem>
878 </varlistentry>
879
880 <varlistentry>
881 <term><varname>$LISTEN_PID</varname></term>
882 <term><varname>$LISTEN_FDS</varname></term>
883
884 <listitem><para>Set by systemd for
885 supervised processes during
886 socket-based activation. See
887 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
888 for more information.
889 </para></listitem>
890 </varlistentry>
891
892 <varlistentry>
893 <term><varname>$NOTIFY_SOCKET</varname></term>
894
895 <listitem><para>Set by systemd for
896 supervised processes for status and
897 start-up completion notification. See
898 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
899 for more information.
900 </para></listitem>
901 </varlistentry>
902 </variablelist>
903 </refsect1>
904
905 <refsect1>
906 <title>Kernel Command Line</title>
907
908 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
909
910 <variablelist>
911 <varlistentry>
912 <term><varname>systemd.unit=</varname></term>
913
914 <listitem><para>Overrides the unit to
915 activate on boot. Defaults to
916 <filename>default.target</filename>. This
917 may be used to temporarily boot into a
918 different boot unit, for example
919 <filename>rescue.target</filename> or
920 <filename>emergency.service</filename>. See
921 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
922 for details about these
923 units.</para></listitem>
924 </varlistentry>
925
926 <varlistentry>
927 <term><varname>systemd.dump_core=</varname></term>
928
929 <listitem><para>Takes a boolean
930 argument. If <option>true</option>
931 systemd dumps core when it
932 crashes. Otherwise no core dump is
933 created. Defaults to
934 <option>true</option>.</para></listitem>
935 </varlistentry>
936
937 <varlistentry>
938 <term><varname>systemd.crash_shell=</varname></term>
939
940 <listitem><para>Takes a boolean
941 argument. If <option>true</option>
942 systemd spawns a shell when it
943 crashes. Otherwise no shell is
944 spawned. Defaults to
945 <option>false</option>, for security
946 reasons, as the shell is not protected
947 by any password
948 authentication.</para></listitem>
949 </varlistentry>
950
951 <varlistentry>
952 <term><varname>systemd.crash_chvt=</varname></term>
953
954 <listitem><para>Takes an integer
955 argument. If positive systemd
956 activates the specified virtual
957 terminal when it crashes. Defaults to
958 <literal>-1</literal>.</para></listitem>
959 </varlistentry>
960
961 <varlistentry>
962 <term><varname>systemd.confirm_spawn=</varname></term>
963
964 <listitem><para>Takes a boolean
965 argument. If <option>true</option>
966 asks for confirmation when spawning
967 processes. Defaults to
968 <option>false</option>.</para></listitem>
969 </varlistentry>
970
971 <varlistentry>
972 <term><varname>systemd.show_status=</varname></term>
973
974 <listitem><para>Takes a boolean
975 argument. If <option>true</option>
976 shows terse service status updates on
977 the console during bootup. Defaults to
978 <option>true</option>.</para></listitem>
979 </varlistentry>
980
981 <varlistentry>
982 <term><varname>systemd.sysv_console=</varname></term>
983
984 <listitem><para>Takes a boolean
985 argument. If <option>true</option>
986 output of SysV init scripts will be
987 directed to the console. Defaults to
988 <option>true</option>, unless
989 <option>quiet</option> is passed as
990 kernel command line option in which
991 case it defaults to
992 <option>false</option>.</para></listitem>
993 </varlistentry>
994
995 <varlistentry>
996 <term><varname>systemd.log_target=</varname></term>
997 <term><varname>systemd.log_level=</varname></term>
998 <term><varname>systemd.log_color=</varname></term>
999 <term><varname>systemd.log_location=</varname></term>
1000
1001 <listitem><para>Controls log output,
1002 with the same effect as the
1003 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
1004 environment variables described above.</para></listitem>
1005 </varlistentry>
1006
1007 <varlistentry>
1008 <term><varname>systemd.default_standard_output=</varname></term>
1009 <term><varname>systemd.default_standard_error=</varname></term>
1010 <listitem><para>Controls default
1011 standard output/error output for
1012 services, with the same effect as the
1013 <option>--default-standard-output=</option>
1014 resp. <option>--default-standard-error=</option>
1015 command line arguments described
1016 above.</para></listitem>
1017 </varlistentry>
1018
1019 </variablelist>
1020 </refsect1>
1021
1022 <refsect1>
1023 <title>Sockets and FIFOs</title>
1024
1025 <variablelist>
1026 <varlistentry>
1027 <term><filename>/run/systemd/notify</filename></term>
1028
1029 <listitem><para>Daemon status
1030 notification socket. This is an
1031 AF_UNIX datagram socket and is used to
1032 implement the daemon notification
1033 logic as implemented by
1034 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1035
1036 </varlistentry>
1037
1038 <varlistentry>
1039 <term><filename>/run/systemd/logger</filename></term>
1040
1041 <listitem><para>Used internally by the
1042 <filename>systemd-logger.service</filename>
1043 unit to connect STDOUT and/or STDERR
1044 of spawned processes to
1045 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
1046 or the kernel log buffer. This is an
1047 AF_UNIX stream
1048 socket.</para></listitem>
1049 </varlistentry>
1050
1051 <varlistentry>
1052 <term><filename>/run/systemd/shutdownd</filename></term>
1053
1054 <listitem><para>Used internally by the
1055 <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1056 tool to implement delayed
1057 shutdowns. This is an AF_UNIX datagram
1058 socket.</para></listitem>
1059 </varlistentry>
1060
1061 <varlistentry>
1062 <term><filename>/run/systemd/private</filename></term>
1063
1064 <listitem><para>Used internally as
1065 communication channel between
1066 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1067 and the systemd process. This is an
1068 AF_UNIX stream socket. This interface
1069 is private to systemd and should not
1070 be used in external
1071 projects.</para></listitem>
1072 </varlistentry>
1073
1074 <varlistentry>
1075 <term><filename>/dev/initctl</filename></term>
1076
1077 <listitem><para>Limited compatibility
1078 support for the SysV client interface,
1079 as implemented by the
1080 <filename>systemd-initctl.service</filename>
1081 unit. This is a named pipe in the file
1082 system. This interface is obsolete and
1083 should not be used in new
1084 applications.</para></listitem>
1085 </varlistentry>
1086 </variablelist>
1087 </refsect1>
1088
1089 <refsect1>
1090 <title>See Also</title>
1091 <para>
1092 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1093 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1094 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1095 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1096 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1097 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1098 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1099 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1100 </para>
1101 </refsect1>
1102
1103 </refentry>