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