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