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>syslog</option>,
213 <option>kmsg</option>,
214 <option>syslog-or-kmsg</option>,
215 <option>null</option>.</para></listitem>
218 <term><option>--log-level=</option></term>
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>
234 <term><option>--log-color=</option></term>
236 <listitem><para>Highlight important
237 log messages. Argument is a boolean
238 value. If the argument is omitted it
240 <option>true</option>.</para></listitem>
243 <term><option>--log-location=</option></term>
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
251 <option>true</option>.</para></listitem>
257 <title>Concepts</title>
259 <para>systemd provides a dependency system between
260 various entities called "units". Units encapsulate
261 various objects that are relevant for system boot-up
262 and maintenance. The majority of units are configured
263 in unit configuration files, whose syntax and basic
264 set of options is described in
265 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
266 however some are created automatically from other
267 configuration or dynamically from system state. Units
268 may be 'active' (meaning started, bound, plugged in,
269 ... depending on the unit type, see below), or
270 'inactive' (meaning stopped, unbound, unplugged, ...),
271 as well as in the process of being activated or
272 deactivated, i.e. between the two states (these states
273 are called 'activating', 'deactivating'). A special
274 'failed' state is available as well which is very
275 similar to 'inactive' and is entered when the service
276 failed in some way (process returned error code on
277 exit, or crashed, or an operation timed out). If this
278 state is entered the cause will be logged, for later
279 reference. Note that the various unit types may have a
280 number of additional substates, which are mapped to
281 the five generalized unit states described
284 <para>The following unit types are available:</para>
287 <listitem><para>Service units, which control
288 daemons and the processes they consist of. For
290 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
292 <listitem><para>Socket units, which
293 encapsulate local IPC or network sockets in
294 the system, useful for socket-based
295 activation. For details about socket units see
296 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
297 for details on socket-based activation and
298 other forms of activation, see
299 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
301 <listitem><para>Target units are useful to
302 group units, or provide well-known
303 synchronization points during boot-up, see
304 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
306 <listitem><para>Device units expose kernel
307 devices in systemd and may be used to
308 implement device-based activation. For details
310 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
312 <listitem><para>Mount units control mount
313 points in the file system, for details see
314 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
316 <listitem><para>Automount units provide
317 automount capabilities, for on-demand mounting
318 of file systems as well as parallelized
320 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
322 <listitem><para>Snapshot units can be used to
323 temporarily save the state of the set of
324 systemd units, which later may be restored by
325 activating the saved snapshot unit. For more
327 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
329 <listitem><para>Timer units are useful for
330 triggering activation of other units based on
331 timers. You may find details in
332 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
334 <listitem><para>Swap units are very similar to
335 mount units and encapsulate memory swap
336 partitions or files of the operating
337 system. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
339 <listitem><para>Path units may be used
340 to activate other services when file system
341 objects change or are modified. See
342 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
346 <para>Units are named as their configuration
347 files. Some units have special semantics. A detailed
349 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
351 <para>systemd knows various kinds of dependencies,
352 including positive and negative requirement
353 dependencies (i.e. <varname>Requires=</varname> and
354 <varname>Conflicts=</varname>) as well as ordering
355 dependencies (<varname>After=</varname> and
356 <varname>Before=</varname>). NB: ordering and
357 requirement dependencies are orthogonal. If only a
358 requirement dependency exists between two units
359 (e.g. <filename>foo.service</filename> requires
360 <filename>bar.service</filename>), but no ordering
361 dependency (e.g. <filename>foo.service</filename>
362 after <filename>bar.service</filename>) and both are
363 requested to start, they will be started in
364 parallel. It is a common pattern that both requirement
365 and ordering dependencies are placed between two
366 units. Also note that the majority of dependencies are
367 implicitly created and maintained by systemd. In most
368 cases it should be unnecessary to declare additional
369 dependencies manually, however it is possible to do
372 <para>Application programs and units (via
373 dependencies) may request state changes of units. In
374 systemd, these requests are encapsulated as 'jobs' and
375 maintained in a job queue. Jobs may succeed or can
376 fail, their execution is ordered based on the ordering
377 dependencies of the units they have been scheduled
380 <para>On boot systemd activates the target unit
381 <filename>default.target</filename> whose job is to
382 activate on-boot services and other on-boot units by
383 pulling them in via dependencies. Usually the unit
384 name is just an alias (symlink) for either
385 <filename>graphical.target</filename> (for
386 fully-featured boots into the UI) or
387 <filename>multi-user.target</filename> (for limited
388 console-only boots for use in embedded or server
389 environments, or similar; a subset of
390 graphical.target). However it is at the discretion of
391 the administrator to configure it as an alias to any
392 other target unit. See
393 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
394 for details about these target units.</para>
396 <para>Processes systemd spawns are placed in
397 individual Linux control groups named after the unit
398 which they belong to in the private systemd
399 hierarchy. (see <ulink
400 url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
401 for more information about control groups, or short
402 "cgroups"). systemd uses this to effectively keep
403 track of processes. Control group information is
404 maintained in the kernel, and is accessible via the
405 file system hierarchy (beneath
406 <filename>/sys/fs/cgroup/systemd/</filename>), or in tools
408 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
409 (<command>ps xawf -eo pid,user,cgroup,args</command>
410 is particularly useful to list all processes and the
411 systemd units they belong to.).</para>
413 <para>systemd is compatible with the SysV init system
414 to a large degree: SysV init scripts are supported and
415 simply read as an alternative (though limited)
416 configuration file format. The SysV
417 <filename>/dev/initctl</filename> interface is
418 provided, and compatibility implementations of the
419 various SysV client tools are available. In addition to
420 that, various established Unix functionality such as
421 <filename>/etc/fstab</filename> or the
422 <filename>utmp</filename> database are
425 <para>systemd has a minimal transaction system: if a
426 unit is requested to start up or shut down it will add
427 it and all its dependencies to a temporary
428 transaction. Then, it will verify if the transaction
429 is consistent (i.e. whether the ordering of all units
430 is cycle-free). If it is not, systemd will try to fix
431 it up, and removes non-essential jobs from the
432 transaction that might remove the loop. Also, systemd
433 tries to suppress non-essential jobs in the
434 transaction that would stop a running service. Finally
435 it is checked whether the jobs of the transaction
436 contradict jobs that have already been queued, and
437 optionally the transaction is aborted then. If all
438 worked out and the transaction is consistent and
439 minimized in its impact it is merged with all already
440 outstanding jobs and added to the run
441 queue. Effectively this means that before executing a
442 requested operation, systemd will verify that it makes
443 sense, fixing it if possible, and only failing if it
444 really cannot work.</para>
446 <para>Systemd contains native implementations of
447 various tasks that need to be executed as part of the
448 boot process. For example, it sets the host name or
449 configures the loopback network device. It also sets
450 up and mounts various API file systems, such as
451 <filename>/sys</filename> or
452 <filename>/proc</filename>.</para>
454 <para>For more information about the concepts and
455 ideas behind systemd please refer to the <ulink
456 url="http://0pointer.de/blog/projects/systemd.html">Original
457 Design Document</ulink>.</para>
459 <para>Note that some but not all interfaces provided
460 by systemd are covered by the <ulink
461 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
462 Stability Promise</ulink>.</para>
466 <title>Directories</title>
470 <term>System unit directories</term>
472 <listitem><para>The systemd system
473 manager reads unit configuration from
474 various directories. Packages that
475 want to install unit files shall place
476 them in the directory returned by
477 <command>pkg-config systemd
478 --variable=systemdsystemunitdir</command>. Other
479 directories checked are
480 <filename>/usr/local/share/systemd/system</filename>
482 <filename>/usr/share/systemd/system</filename>. User
483 configuration always takes
484 precedence. <command>pkg-config
486 --variable=systemdsystemconfdir</command>
487 returns the path of the system
488 configuration directory. Packages
489 should alter the content of these
490 directories only with the
491 <command>enable</command> and
492 <command>disable</command> commands of
494 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
495 tool.</para></listitem>
501 <term>User unit directories</term>
503 <listitem><para>Similar rules apply
505 directories. However, here the <ulink
506 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
507 Base Directory specification</ulink>
509 units. Applications should place their
510 unit files in the directory returned
511 by <command>pkg-config systemd
512 --variable=systemduserunitdir</command>. Global
513 configuration is done in the directory
514 reported by <command>pkg-config
516 --variable=systemduserconfdir</command>. The
517 <command>enable</command> and
518 <command>disable</command> commands of
520 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
521 tool can handle both global (i.e. for
522 all users) and private (for one user)
523 enabling/disabling of
524 units.</para></listitem>
530 <term>SysV init scripts directory</term>
532 <listitem><para>The location of the
533 SysV init script directory varies
534 between distributions. If systemd
535 cannot find a native unit file for a
536 requested service, it will look for a
537 SysV init script of the same name
539 <filename>.service</filename> suffix
540 removed).</para></listitem>
546 <term>SysV runlevel link farm directory</term>
548 <listitem><para>The location of the
549 SysV runlevel link farm directory
550 varies between distributions. systemd
551 will take the link farm into account
552 when figuring out whether a service
553 shall be enabled. Note that a service
554 unit with a native unit configuration
555 file cannot be started by activating it
556 in the SysV runlevel link
557 farm.</para></listitem>
563 <title>Signals</title>
569 <listitem><para>Upon receiving this
570 signal the systemd system manager
571 serializes its state, reexecutes
572 itself and deserializes the saved
573 state again. This is mostly equivalent
574 to <command>systemctl
575 daemon-reexec</command>.</para>
577 <para>systemd user managers will
579 <filename>exit.target</filename> unit
580 when this signal is received. This is
582 <command>systemctl --user start
583 exit.target</command>.</para></listitem>
589 <listitem><para>Upon receiving this
590 signal the systemd system manager will
592 <filename>ctrl-alt-del.target</filename> unit. This
593 is mostly equivalent to
594 <command>systemctl start
595 ctl-alt-del.target</command>.</para>
597 <para>systemd user managers
598 treat this signal the same way as
599 SIGTERM.</para></listitem>
603 <term>SIGWINCH</term>
605 <listitem><para>When this signal is
606 received the systemd system manager
608 <filename>kbrequest.target</filename>
609 unit. This is mostly equivalent to
610 <command>systemctl start
611 kbrequest.target</command>.</para>
613 <para>This signal is ignored by
615 managers.</para></listitem>
621 <listitem><para>When this signal is
622 received the systemd manager
624 <filename>sigpwr.target</filename>
625 unit. This is mostly equivalent to
626 <command>systemctl start
627 sigpwr.target</command>.</para></listitem>
633 <listitem><para>When this signal is
634 received the systemd manager will try
635 to reconnect to the D-Bus
636 bus.</para></listitem>
642 <listitem><para>When this signal is
643 received the systemd manager will log
644 its complete state in human readable
645 form. The data logged is the same as
646 printed by <command>systemctl
647 dump</command>.</para></listitem>
653 <listitem><para>Reloads the complete
654 daemon configuration. This is mostly
655 equivalent to <command>systemctl
656 daemon-reload</command>.</para></listitem>
660 <term>SIGRTMIN+0</term>
662 <listitem><para>Enters default mode, starts the
663 <filename>default.target</filename>
664 unit. This is mostly equivalent to
665 <command>systemctl start
666 default.target</command>.</para></listitem>
670 <term>SIGRTMIN+1</term>
672 <listitem><para>Enters rescue mode,
674 <filename>rescue.target</filename>
675 unit. This is mostly equivalent to
676 <command>systemctl isolate
677 rescue.target</command>.</para></listitem>
681 <term>SIGRTMIN+2</term>
683 <listitem><para>Enters emergency mode,
685 <filename>emergency.service</filename>
686 unit. This is mostly equivalent to
687 <command>systemctl isolate
688 emergency.service</command>.</para></listitem>
692 <term>SIGRTMIN+3</term>
694 <listitem><para>Halts the machine,
696 <filename>halt.target</filename>
697 unit. This is mostly equivalent to
698 <command>systemctl start
699 halt.target</command>.</para></listitem>
703 <term>SIGRTMIN+4</term>
705 <listitem><para>Powers off the machine,
707 <filename>poweroff.target</filename>
708 unit. This is mostly equivalent to
709 <command>systemctl start
710 poweroff.target</command>.</para></listitem>
714 <term>SIGRTMIN+5</term>
716 <listitem><para>Reboots the machine,
718 <filename>reboot.target</filename>
719 unit. This is mostly equivalent to
720 <command>systemctl start
721 reboot.target</command>.</para></listitem>
725 <term>SIGRTMIN+6</term>
727 <listitem><para>Reboots the machine via kexec,
729 <filename>kexec.target</filename>
730 unit. This is mostly equivalent to
731 <command>systemctl start
732 kexec.target</command>.</para></listitem>
736 <term>SIGRTMIN+13</term>
738 <listitem><para>Immediately halts the machine.</para></listitem>
742 <term>SIGRTMIN+14</term>
744 <listitem><para>Immediately powers off the machine.</para></listitem>
748 <term>SIGRTMIN+15</term>
750 <listitem><para>Immediately reboots the machine.</para></listitem>
754 <term>SIGRTMIN+16</term>
756 <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
760 <term>SIGRTMIN+20</term>
762 <listitem><para>Enables display of
763 status messages on the console, as
765 <varname>systemd.show_status=1</varname>
766 on the kernel command
767 line.</para></listitem>
771 <term>SIGRTMIN+21</term>
773 <listitem><para>Disables display of
774 status messages on the console, as
776 <varname>systemd.show_status=0</varname>
777 on the kernel command
778 line.</para></listitem>
784 <title>Environment</title>
788 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
789 <listitem><para>systemd reads the
790 log level from this environment
791 variable. This can be overridden with
792 <option>--log-level=</option>.</para></listitem>
796 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
797 <listitem><para>systemd reads the
798 log target from this environment
799 variable. This can be overridden with
800 <option>--log-target=</option>.</para></listitem>
804 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
805 <listitem><para>Controls whether
806 systemd highlights important log
807 messages. This can be overridden with
808 <option>--log-color=</option>.</para></listitem>
812 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
813 <listitem><para>Controls whether
814 systemd prints the code location along
815 with log messages. This can be
817 <option>--log-location=</option>.</para></listitem>
821 <term><varname>$XDG_CONFIG_HOME</varname></term>
822 <term><varname>$XDG_CONFIG_DIRS</varname></term>
823 <term><varname>$XDG_DATA_HOME</varname></term>
824 <term><varname>$XDG_DATA_DIRS</varname></term>
826 <listitem><para>The systemd user
827 manager uses these variables in
828 accordance to the <ulink
829 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
830 Base Directory specification</ulink>
831 to find its configuration.</para></listitem>
835 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
837 <listitem><para>Controls where systemd
839 files.</para></listitem>
843 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
845 <listitem><para>Controls where systemd
846 looks for SysV init scripts.</para></listitem>
850 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
852 <listitem><para>Controls where systemd
853 looks for SysV init script runlevel link
854 farms.</para></listitem>
858 <term><varname>$LISTEN_PID</varname></term>
859 <term><varname>$LISTEN_FDS</varname></term>
861 <listitem><para>Set by systemd for
862 supervised processes during
863 socket-based activation. See
864 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
865 for more information.
870 <term><varname>$NOTIFY_SOCKET</varname></term>
872 <listitem><para>Set by systemd for
873 supervised processes for status and
874 start-up completion notification. See
875 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
876 for more information.
883 <title>Kernel Command Line</title>
885 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
889 <term><varname>systemd.unit=</varname></term>
891 <listitem><para>Overrides the unit to
892 activate on boot. Defaults to
893 <filename>default.target</filename>. This
894 may be used to temporarily boot into a
895 different boot unit, for example
896 <filename>rescue.target</filename> or
897 <filename>emergency.service</filename>. See
898 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
899 for details about these
900 units.</para></listitem>
904 <term><varname>systemd.dump_core=</varname></term>
906 <listitem><para>Takes a boolean
907 argument. If <option>true</option>
908 systemd dumps core when it
909 crashes. Otherwise no core dump is
911 <option>true</option>.</para></listitem>
915 <term><varname>systemd.crash_shell=</varname></term>
917 <listitem><para>Takes a boolean
918 argument. If <option>true</option>
919 systemd spawns a shell when it
920 crashes. Otherwise no shell is
922 <option>false</option>, for security
923 reasons, as the shell is not protected
925 authentication.</para></listitem>
929 <term><varname>systemd.crash_chvt=</varname></term>
931 <listitem><para>Takes an integer
932 argument. If positive systemd
933 activates the specified virtual
934 terminal when it crashes. Defaults to
935 <literal>-1</literal>.</para></listitem>
939 <term><varname>systemd.confirm_spawn=</varname></term>
941 <listitem><para>Takes a boolean
942 argument. If <option>true</option>
943 asks for confirmation when spawning
944 processes. Defaults to
945 <option>false</option>.</para></listitem>
949 <term><varname>systemd.show_status=</varname></term>
951 <listitem><para>Takes a boolean
952 argument. If <option>true</option>
953 shows terse service status updates on
954 the console during bootup. Defaults to
955 <option>true</option>.</para></listitem>
959 <term><varname>systemd.sysv_console=</varname></term>
961 <listitem><para>Takes a boolean
962 argument. If <option>true</option>
963 output of SysV init scripts will be
964 directed to the console. Defaults to
965 <option>true</option>, unless
966 <option>quiet</option> is passed as
967 kernel command line option in which
969 <option>false</option>.</para></listitem>
973 <term><varname>systemd.log_target=</varname></term>
974 <term><varname>systemd.log_level=</varname></term>
975 <term><varname>systemd.log_color=</varname></term>
976 <term><varname>systemd.log_location=</varname></term>
978 <listitem><para>Controls log output,
979 with the same effect as the
980 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
981 environment variables described above.</para></listitem>
988 <title>Sockets and FIFOs</title>
992 <term><filename>@/org/freedesktop/systemd1/notify</filename></term>
994 <listitem><para>Daemon status
995 notification socket. This is an AF_UNIX
996 datagram socket in the Linux abstract
997 namespace, and is used to implement
998 the daemon notification logic as
1000 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1005 <term><filename>@/org/freedesktop/systemd1/logger</filename></term>
1007 <listitem><para>Used internally by the
1008 <filename>systemd-logger.service</filename>
1009 unit to connect STDOUT and/or STDERR
1010 of spawned processes to
1011 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
1012 or the kernel log buffer. This is an
1013 AF_UNIX stream socket in the Linux
1014 abstract namespace.</para></listitem>
1018 <term><filename>@/org/freedesktop/systemd1/shutdown</filename></term>
1020 <listitem><para>Used internally by the
1021 <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1022 tool to implement delayed
1023 shutdowns. This is an AF_UNIX datagram
1024 socket in the Linux abstract
1025 namespace.</para></listitem>
1029 <term><filename>@/org/freedesktop/systemd1/private</filename></term>
1031 <listitem><para>Used internally as
1032 communication channel between
1033 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1034 and the systemd process. This is an
1035 AF_UNIX stream socket in the Linux
1036 abstract namespace. This interface is
1037 private to systemd and should not be
1039 projects.</para></listitem>
1043 <term><filename>/dev/initctl</filename></term>
1045 <listitem><para>Limited compatibility
1046 support for the SysV client interface,
1047 as implemented by the
1048 <filename>systemd-initctl.service</filename>
1049 unit. This is a named pipe in the file
1050 system. This interface is obsolete and
1051 should not be used in new
1052 applications.</para></listitem>
1058 <title>See Also</title>
1060 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1061 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1062 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1063 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1064 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1065 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1066 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1067 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>