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