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