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