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">
6 This file is part of systemd.
8 Copyright 2010 Lennart Poettering
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.
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.
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/>.
24 <refentry id="systemd">
27 <title>systemd</title>
28 <productname>systemd</productname>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
41 <refentrytitle>systemd</refentrytitle>
42 <manvolnum>1</manvolnum>
46 <refname>systemd</refname>
47 <refname>init</refname>
48 <refpurpose>systemd System and Service Manager</refpurpose>
53 <command>systemd <arg choice="opt" rep="repeat">OPTIONS</arg></command>
56 <command>init <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
61 <title>Description</title>
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>
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>
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>
86 <title>Options</title>
88 <para>The following options are understood:</para>
92 <term><option>-h</option></term>
93 <term><option>--help</option></term>
95 <listitem><para>Prints a short help
96 text and exits.</para></listitem>
99 <term><option>--test</option></term>
101 <listitem><para>Determine startup
102 sequence, dump it and exit. This is an
103 option useful for debugging
104 only.</para></listitem>
107 <term><option>--dump-configuration-items</option></term>
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>
116 <term><option>--introspect=</option></term>
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
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>
130 <term><option>--unit=</option></term>
132 <listitem><para>Set default unit to
133 activate on startup. If not specified
135 <filename>default.target</filename>.</para></listitem>
138 <term><option>--system</option></term>
139 <term><option>--user</option></term>
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>
160 <term><option>--dump-core</option></term>
162 <listitem><para>Dump core on
163 crash. This switch has no effect when
165 instance.</para></listitem>
168 <term><option>--crash-shell</option></term>
170 <listitem><para>Run shell on
171 crash. This switch has no effect when
173 instance.</para></listitem>
176 <term><option>--confirm-spawn</option></term>
178 <listitem><para>Ask for confirmation
179 when spawning processes. This switch
180 has no effect when run as user
181 instance.</para></listitem>
184 <term><option>--show-status=</option></term>
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
192 <option>true</option>.</para></listitem>
195 <term><option>--sysv-console=</option></term>
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
204 <option>true</option>.</para></listitem>
207 <term><option>--log-target=</option></term>
209 <listitem><para>Set log
210 target. Argument must be one of
211 <option>console</option>,
212 <option>journal</option>,
213 <option>syslog</option>,
214 <option>kmsg</option>,
215 <option>journal-or-kmsg</option>,
216 <option>syslog-or-kmsg</option>,
217 <option>null</option>.</para></listitem>
220 <term><option>--log-level=</option></term>
222 <listitem><para>Set log level. As
223 argument this accepts a numerical log
224 level or the well-known <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
225 symbolic names (lowercase):
226 <option>emerg</option>,
227 <option>alert</option>,
228 <option>crit</option>,
229 <option>err</option>,
230 <option>warning</option>,
231 <option>notice</option>,
232 <option>info</option>,
233 <option>debug</option>.</para></listitem>
236 <term><option>--log-color=</option></term>
238 <listitem><para>Highlight important
239 log messages. Argument is a boolean
240 value. If the argument is omitted it
242 <option>true</option>.</para></listitem>
245 <term><option>--log-location=</option></term>
247 <listitem><para>Include code location
248 in log messages. This is mostly
249 relevant for debugging
250 purposes. Argument is a boolean
251 value. If the argument is omitted
253 <option>true</option>.</para></listitem>
256 <term><option>--default-standard-output=</option></term>
257 <term><option>--default-standard-error=</option></term>
259 <listitem><para>Sets the default
260 output resp. error output for all
261 services and sockets, i.e. controls
263 <option>StandardOutput=</option>
264 resp. <option>StandardError=</option>
266 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
267 for details). Takes one of
268 <option>inherit</option>,
269 <option>null</option>,
270 <option>tty</option>,
271 <option>journal</option>,
272 <option>journal+console</option>,
273 <option>syslog</option>,
274 <option>syslog+console</option>,
275 <option>kmsg</option>,
276 <option>kmsg+console</option>. If the
278 <option>--default-standard-output=</option>
279 defaults to <option>journal</option>
281 <option>--default-standard-error=</option>
283 <option>inherit</option>.</para></listitem>
289 <title>Concepts</title>
291 <para>systemd provides a dependency system between
292 various entities called "units". Units encapsulate
293 various objects that are relevant for system boot-up
294 and maintenance. The majority of units are configured
295 in unit configuration files, whose syntax and basic
296 set of options is described in
297 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
298 however some are created automatically from other
299 configuration or dynamically from system state. Units
300 may be 'active' (meaning started, bound, plugged in,
301 ... depending on the unit type, see below), or
302 'inactive' (meaning stopped, unbound, unplugged, ...),
303 as well as in the process of being activated or
304 deactivated, i.e. between the two states (these states
305 are called 'activating', 'deactivating'). A special
306 'failed' state is available as well which is very
307 similar to 'inactive' and is entered when the service
308 failed in some way (process returned error code on
309 exit, or crashed, or an operation timed out). If this
310 state is entered the cause will be logged, for later
311 reference. Note that the various unit types may have a
312 number of additional substates, which are mapped to
313 the five generalized unit states described
316 <para>The following unit types are available:</para>
319 <listitem><para>Service units, which control
320 daemons and the processes they consist of. For
322 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
324 <listitem><para>Socket units, which
325 encapsulate local IPC or network sockets in
326 the system, useful for socket-based
327 activation. For details about socket units see
328 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
329 for details on socket-based activation and
330 other forms of activation, see
331 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
333 <listitem><para>Target units are useful to
334 group units, or provide well-known
335 synchronization points during boot-up, see
336 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
338 <listitem><para>Device units expose kernel
339 devices in systemd and may be used to
340 implement device-based activation. For details
342 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
344 <listitem><para>Mount units control mount
345 points in the file system, for details see
346 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
348 <listitem><para>Automount units provide
349 automount capabilities, for on-demand mounting
350 of file systems as well as parallelized
352 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
354 <listitem><para>Snapshot units can be used to
355 temporarily save the state of the set of
356 systemd units, which later may be restored by
357 activating the saved snapshot unit. For more
359 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
361 <listitem><para>Timer units are useful for
362 triggering activation of other units based on
363 timers. You may find details in
364 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
366 <listitem><para>Swap units are very similar to
367 mount units and encapsulate memory swap
368 partitions or files of the operating
369 system. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
371 <listitem><para>Path units may be used
372 to activate other services when file system
373 objects change or are modified. See
374 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
378 <para>Units are named as their configuration
379 files. Some units have special semantics. A detailed
381 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
383 <para>systemd knows various kinds of dependencies,
384 including positive and negative requirement
385 dependencies (i.e. <varname>Requires=</varname> and
386 <varname>Conflicts=</varname>) as well as ordering
387 dependencies (<varname>After=</varname> and
388 <varname>Before=</varname>). NB: ordering and
389 requirement dependencies are orthogonal. If only a
390 requirement dependency exists between two units
391 (e.g. <filename>foo.service</filename> requires
392 <filename>bar.service</filename>), but no ordering
393 dependency (e.g. <filename>foo.service</filename>
394 after <filename>bar.service</filename>) and both are
395 requested to start, they will be started in
396 parallel. It is a common pattern that both requirement
397 and ordering dependencies are placed between two
398 units. Also note that the majority of dependencies are
399 implicitly created and maintained by systemd. In most
400 cases it should be unnecessary to declare additional
401 dependencies manually, however it is possible to do
404 <para>Application programs and units (via
405 dependencies) may request state changes of units. In
406 systemd, these requests are encapsulated as 'jobs' and
407 maintained in a job queue. Jobs may succeed or can
408 fail, their execution is ordered based on the ordering
409 dependencies of the units they have been scheduled
412 <para>On boot systemd activates the target unit
413 <filename>default.target</filename> whose job is to
414 activate on-boot services and other on-boot units by
415 pulling them in via dependencies. Usually the unit
416 name is just an alias (symlink) for either
417 <filename>graphical.target</filename> (for
418 fully-featured boots into the UI) or
419 <filename>multi-user.target</filename> (for limited
420 console-only boots for use in embedded or server
421 environments, or similar; a subset of
422 graphical.target). However it is at the discretion of
423 the administrator to configure it as an alias to any
424 other target unit. See
425 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
426 for details about these target units.</para>
428 <para>Processes systemd spawns are placed in
429 individual Linux control groups named after the unit
430 which they belong to in the private systemd
431 hierarchy. (see <ulink
432 url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
433 for more information about control groups, or short
434 "cgroups"). systemd uses this to effectively keep
435 track of processes. Control group information is
436 maintained in the kernel, and is accessible via the
437 file system hierarchy (beneath
438 <filename>/sys/fs/cgroup/systemd/</filename>), or in tools
440 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
441 (<command>ps xawf -eo pid,user,cgroup,args</command>
442 is particularly useful to list all processes and the
443 systemd units they belong to.).</para>
445 <para>systemd is compatible with the SysV init system
446 to a large degree: SysV init scripts are supported and
447 simply read as an alternative (though limited)
448 configuration file format. The SysV
449 <filename>/dev/initctl</filename> interface is
450 provided, and compatibility implementations of the
451 various SysV client tools are available. In addition to
452 that, various established Unix functionality such as
453 <filename>/etc/fstab</filename> or the
454 <filename>utmp</filename> database are
457 <para>systemd has a minimal transaction system: if a
458 unit is requested to start up or shut down it will add
459 it and all its dependencies to a temporary
460 transaction. Then, it will verify if the transaction
461 is consistent (i.e. whether the ordering of all units
462 is cycle-free). If it is not, systemd will try to fix
463 it up, and removes non-essential jobs from the
464 transaction that might remove the loop. Also, systemd
465 tries to suppress non-essential jobs in the
466 transaction that would stop a running service. Finally
467 it is checked whether the jobs of the transaction
468 contradict jobs that have already been queued, and
469 optionally the transaction is aborted then. If all
470 worked out and the transaction is consistent and
471 minimized in its impact it is merged with all already
472 outstanding jobs and added to the run
473 queue. Effectively this means that before executing a
474 requested operation, systemd will verify that it makes
475 sense, fixing it if possible, and only failing if it
476 really cannot work.</para>
478 <para>Systemd contains native implementations of
479 various tasks that need to be executed as part of the
480 boot process. For example, it sets the host name or
481 configures the loopback network device. It also sets
482 up and mounts various API file systems, such as
483 <filename>/sys</filename> or
484 <filename>/proc</filename>.</para>
486 <para>For more information about the concepts and
487 ideas behind systemd please refer to the <ulink
488 url="http://0pointer.de/blog/projects/systemd.html">Original
489 Design Document</ulink>.</para>
491 <para>Note that some but not all interfaces provided
492 by systemd are covered by the <ulink
493 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
494 Stability Promise</ulink>.</para>
498 <title>Directories</title>
502 <term>System unit directories</term>
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>
514 <filename>/usr/lib/systemd/system</filename>. User
515 configuration always takes
516 precedence. <command>pkg-config
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
526 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
527 tool.</para></listitem>
533 <term>User unit directories</term>
535 <listitem><para>Similar rules apply
537 directories. However, here the <ulink
538 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
539 Base Directory specification</ulink>
541 units. Applications should place their
542 unit files in the directory returned
543 by <command>pkg-config systemd
544 --variable=systemduserunitdir</command>. Global
545 configuration is done in the directory
546 reported by <command>pkg-config
548 --variable=systemduserconfdir</command>. The
549 <command>enable</command> and
550 <command>disable</command> commands of
552 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
553 tool can handle both global (i.e. for
554 all users) and private (for one user)
555 enabling/disabling of
556 units.</para></listitem>
562 <term>SysV init scripts directory</term>
564 <listitem><para>The location of the
565 SysV init script directory varies
566 between distributions. If systemd
567 cannot find a native unit file for a
568 requested service, it will look for a
569 SysV init script of the same name
571 <filename>.service</filename> suffix
572 removed).</para></listitem>
578 <term>SysV runlevel link farm directory</term>
580 <listitem><para>The location of the
581 SysV runlevel link farm directory
582 varies between distributions. systemd
583 will take the link farm into account
584 when figuring out whether a service
585 shall be enabled. Note that a service
586 unit with a native unit configuration
587 file cannot be started by activating it
588 in the SysV runlevel link
589 farm.</para></listitem>
595 <title>Signals</title>
601 <listitem><para>Upon receiving this
602 signal the systemd system manager
603 serializes its state, reexecutes
604 itself and deserializes the saved
605 state again. This is mostly equivalent
606 to <command>systemctl
607 daemon-reexec</command>.</para>
609 <para>systemd user managers will
611 <filename>exit.target</filename> unit
612 when this signal is received. This is
614 <command>systemctl --user start
615 exit.target</command>.</para></listitem>
621 <listitem><para>Upon receiving this
622 signal the systemd system manager will
624 <filename>ctrl-alt-del.target</filename> unit. This
625 is mostly equivalent to
626 <command>systemctl start
627 ctl-alt-del.target</command>.</para>
629 <para>systemd user managers
630 treat this signal the same way as
631 SIGTERM.</para></listitem>
635 <term>SIGWINCH</term>
637 <listitem><para>When this signal is
638 received the systemd system manager
640 <filename>kbrequest.target</filename>
641 unit. This is mostly equivalent to
642 <command>systemctl start
643 kbrequest.target</command>.</para>
645 <para>This signal is ignored by
647 managers.</para></listitem>
653 <listitem><para>When this signal is
654 received the systemd manager
656 <filename>sigpwr.target</filename>
657 unit. This is mostly equivalent to
658 <command>systemctl start
659 sigpwr.target</command>.</para></listitem>
665 <listitem><para>When this signal is
666 received the systemd manager will try
667 to reconnect to the D-Bus
668 bus.</para></listitem>
674 <listitem><para>When this signal is
675 received the systemd manager will log
676 its complete state in human readable
677 form. The data logged is the same as
678 printed by <command>systemctl
679 dump</command>.</para></listitem>
685 <listitem><para>Reloads the complete
686 daemon configuration. This is mostly
687 equivalent to <command>systemctl
688 daemon-reload</command>.</para></listitem>
692 <term>SIGRTMIN+0</term>
694 <listitem><para>Enters default mode, starts the
695 <filename>default.target</filename>
696 unit. This is mostly equivalent to
697 <command>systemctl start
698 default.target</command>.</para></listitem>
702 <term>SIGRTMIN+1</term>
704 <listitem><para>Enters rescue mode,
706 <filename>rescue.target</filename>
707 unit. This is mostly equivalent to
708 <command>systemctl isolate
709 rescue.target</command>.</para></listitem>
713 <term>SIGRTMIN+2</term>
715 <listitem><para>Enters emergency mode,
717 <filename>emergency.service</filename>
718 unit. This is mostly equivalent to
719 <command>systemctl isolate
720 emergency.service</command>.</para></listitem>
724 <term>SIGRTMIN+3</term>
726 <listitem><para>Halts the machine,
728 <filename>halt.target</filename>
729 unit. This is mostly equivalent to
730 <command>systemctl start
731 halt.target</command>.</para></listitem>
735 <term>SIGRTMIN+4</term>
737 <listitem><para>Powers off the machine,
739 <filename>poweroff.target</filename>
740 unit. This is mostly equivalent to
741 <command>systemctl start
742 poweroff.target</command>.</para></listitem>
746 <term>SIGRTMIN+5</term>
748 <listitem><para>Reboots the machine,
750 <filename>reboot.target</filename>
751 unit. This is mostly equivalent to
752 <command>systemctl start
753 reboot.target</command>.</para></listitem>
757 <term>SIGRTMIN+6</term>
759 <listitem><para>Reboots the machine via kexec,
761 <filename>kexec.target</filename>
762 unit. This is mostly equivalent to
763 <command>systemctl start
764 kexec.target</command>.</para></listitem>
768 <term>SIGRTMIN+13</term>
770 <listitem><para>Immediately halts the machine.</para></listitem>
774 <term>SIGRTMIN+14</term>
776 <listitem><para>Immediately powers off the machine.</para></listitem>
780 <term>SIGRTMIN+15</term>
782 <listitem><para>Immediately reboots the machine.</para></listitem>
786 <term>SIGRTMIN+16</term>
788 <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
792 <term>SIGRTMIN+20</term>
794 <listitem><para>Enables display of
795 status messages on the console, as
797 <varname>systemd.show_status=1</varname>
798 on the kernel command
799 line.</para></listitem>
803 <term>SIGRTMIN+21</term>
805 <listitem><para>Disables display of
806 status messages on the console, as
808 <varname>systemd.show_status=0</varname>
809 on the kernel command
810 line.</para></listitem>
814 <term>SIGRTMIN+22</term>
815 <term>SIGRTMIN+23</term>
817 <listitem><para>Sets the log level to
818 <literal>debug</literal>
819 (resp. <literal>info</literal> on
820 <literal>SIGRTMIN+23</literal>), as
822 <varname>systemd.log_level=debug</varname>
823 (resp. <varname>systemd.log_level=info</varname>
824 on <literal>SIGRTMIN+23</literal>) on
826 line.</para></listitem>
830 <term>SIGRTMIN+26</term>
831 <term>SIGRTMIN+27</term>
832 <term>SIGRTMIN+28</term>
833 <term>SIGRTMIN+29</term>
835 <listitem><para>Sets the log level to
836 <literal>journal-or-kmsg</literal>
837 (resp. <literal>console</literal> on
838 <literal>SIGRTMIN+27</literal>;
839 resp. <literal>kmsg</literal> on
840 <literal>SIGRTMIN+28</literal>;
841 resp. <literal>syslog-or-kmsg</literal>
842 on <literal>SIGRTMIN+29</literal>), as
844 <varname>systemd.log_target=journal-or-kmsg</varname>
845 (resp. <varname>systemd.log_target=console</varname>
846 on <literal>SIGRTMIN+27</literal>;
847 resp. <varname>systemd.log_target=kmsg</varname>
848 on <literal>SIGRTMIN+28</literal>;
850 <varname>systemd.log_target=syslog-or-kmsg</varname>
851 on <literal>SIGRTMIN+29</literal>) on
853 line.</para></listitem>
859 <title>Environment</title>
863 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
864 <listitem><para>systemd reads the
865 log level from this environment
866 variable. This can be overridden with
867 <option>--log-level=</option>.</para></listitem>
871 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
872 <listitem><para>systemd reads the
873 log target from this environment
874 variable. This can be overridden with
875 <option>--log-target=</option>.</para></listitem>
879 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
880 <listitem><para>Controls whether
881 systemd highlights important log
882 messages. This can be overridden with
883 <option>--log-color=</option>.</para></listitem>
887 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
888 <listitem><para>Controls whether
889 systemd prints the code location along
890 with log messages. This can be
892 <option>--log-location=</option>.</para></listitem>
896 <term><varname>$XDG_CONFIG_HOME</varname></term>
897 <term><varname>$XDG_CONFIG_DIRS</varname></term>
898 <term><varname>$XDG_DATA_HOME</varname></term>
899 <term><varname>$XDG_DATA_DIRS</varname></term>
901 <listitem><para>The systemd user
902 manager uses these variables in
903 accordance to the <ulink
904 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
905 Base Directory specification</ulink>
906 to find its configuration.</para></listitem>
910 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
912 <listitem><para>Controls where systemd
914 files.</para></listitem>
918 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
920 <listitem><para>Controls where systemd
921 looks for SysV init scripts.</para></listitem>
925 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
927 <listitem><para>Controls where systemd
928 looks for SysV init script runlevel link
929 farms.</para></listitem>
933 <term><varname>$LISTEN_PID</varname></term>
934 <term><varname>$LISTEN_FDS</varname></term>
936 <listitem><para>Set by systemd for
937 supervised processes during
938 socket-based activation. See
939 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
940 for more information.
945 <term><varname>$NOTIFY_SOCKET</varname></term>
947 <listitem><para>Set by systemd for
948 supervised processes for status and
949 start-up completion notification. See
950 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
951 for more information.
958 <title>Kernel Command Line</title>
960 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
964 <term><varname>systemd.unit=</varname></term>
966 <listitem><para>Overrides the unit to
967 activate on boot. Defaults to
968 <filename>default.target</filename>. This
969 may be used to temporarily boot into a
970 different boot unit, for example
971 <filename>rescue.target</filename> or
972 <filename>emergency.service</filename>. See
973 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
974 for details about these
975 units.</para></listitem>
979 <term><varname>systemd.dump_core=</varname></term>
981 <listitem><para>Takes a boolean
982 argument. If <option>true</option>
983 systemd dumps core when it
984 crashes. Otherwise no core dump is
986 <option>true</option>.</para></listitem>
990 <term><varname>systemd.crash_shell=</varname></term>
992 <listitem><para>Takes a boolean
993 argument. If <option>true</option>
994 systemd spawns a shell when it
995 crashes. Otherwise no shell is
997 <option>false</option>, for security
998 reasons, as the shell is not protected
1000 authentication.</para></listitem>
1004 <term><varname>systemd.crash_chvt=</varname></term>
1006 <listitem><para>Takes an integer
1007 argument. If positive systemd
1008 activates the specified virtual
1009 terminal when it crashes. Defaults to
1010 <literal>-1</literal>.</para></listitem>
1014 <term><varname>systemd.confirm_spawn=</varname></term>
1016 <listitem><para>Takes a boolean
1017 argument. If <option>true</option>
1018 asks for confirmation when spawning
1019 processes. Defaults to
1020 <option>false</option>.</para></listitem>
1024 <term><varname>systemd.show_status=</varname></term>
1026 <listitem><para>Takes a boolean
1027 argument. If <option>true</option>
1028 shows terse service status updates on
1029 the console during bootup. Defaults to
1030 <option>true</option>.</para></listitem>
1034 <term><varname>systemd.sysv_console=</varname></term>
1036 <listitem><para>Takes a boolean
1037 argument. If <option>true</option>
1038 output of SysV init scripts will be
1039 directed to the console. Defaults to
1040 <option>true</option>, unless
1041 <option>quiet</option> is passed as
1042 kernel command line option in which
1044 <option>false</option>.</para></listitem>
1048 <term><varname>systemd.log_target=</varname></term>
1049 <term><varname>systemd.log_level=</varname></term>
1050 <term><varname>systemd.log_color=</varname></term>
1051 <term><varname>systemd.log_location=</varname></term>
1053 <listitem><para>Controls log output,
1054 with the same effect as the
1055 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
1056 environment variables described above.</para></listitem>
1060 <term><varname>systemd.default_standard_output=</varname></term>
1061 <term><varname>systemd.default_standard_error=</varname></term>
1062 <listitem><para>Controls default
1063 standard output/error output for
1064 services, with the same effect as the
1065 <option>--default-standard-output=</option>
1066 resp. <option>--default-standard-error=</option>
1067 command line arguments described
1068 above.</para></listitem>
1072 <term><varname>systemd.setenv=</varname></term>
1074 <listitem><para>Takes a string
1075 argument in the form
1076 VARIABLE=VALUE. May be used to set
1077 environment variables for the init
1078 process and all its children at boot
1079 time. May be used more than once to
1080 set multiple variables. If the equal
1081 sign and variable are missing unsets
1082 an environment variable which might be
1083 passed in from the initial ram
1084 disk.</para></listitem>
1091 <title>Sockets and FIFOs</title>
1095 <term><filename>/run/systemd/notify</filename></term>
1097 <listitem><para>Daemon status
1098 notification socket. This is an
1099 AF_UNIX datagram socket and is used to
1100 implement the daemon notification
1101 logic as implemented by
1102 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1107 <term><filename>/run/systemd/shutdownd</filename></term>
1109 <listitem><para>Used internally by the
1110 <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1111 tool to implement delayed
1112 shutdowns. This is an AF_UNIX datagram
1113 socket.</para></listitem>
1117 <term><filename>/run/systemd/private</filename></term>
1119 <listitem><para>Used internally as
1120 communication channel between
1121 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1122 and the systemd process. This is an
1123 AF_UNIX stream socket. This interface
1124 is private to systemd and should not
1126 projects.</para></listitem>
1130 <term><filename>/dev/initctl</filename></term>
1132 <listitem><para>Limited compatibility
1133 support for the SysV client interface,
1134 as implemented by the
1135 <filename>systemd-initctl.service</filename>
1136 unit. This is a named pipe in the file
1137 system. This interface is obsolete and
1138 should not be used in new
1139 applications.</para></listitem>
1145 <title>See Also</title>
1147 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1148 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1149 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1150 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1151 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1152 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1153 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1154 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>