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 Session 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 session 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>session.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>--session</option></term>
141 <listitem><para>Tell systemd to run a
142 system instance (resp. session
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 crash. This switch has no effect when run as session instance.</para></listitem>
165 <term><option>--crash-shell</option></term>
167 <listitem><para>Run shell on crash. This switch has no effect when run as session instance.</para></listitem>
170 <term><option>--confirm-spawn</option></term>
172 <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as session instance.</para></listitem>
175 <term><option>--show-status=</option></term>
177 <listitem><para>Show terse service
178 status information while booting. This
179 switch has no effect when run as
180 session instance. Takes a boolean
181 argument which may be omitted
182 which is interpreted as
183 <option>true</option>.</para></listitem>
186 <term><option>--sysv-console=</option></term>
188 <listitem><para>Controls whether
189 output of SysV init scripts will be
190 directed to the console. This switch
191 has no effect when run as session
192 instance. Takes a boolean argument
193 which may be omitted which is
195 <option>true</option>.</para></listitem>
198 <term><option>--log-target=</option></term>
200 <listitem><para>Set log
201 target. Argument must be one of
202 <option>console</option>,
203 <option>syslog</option>,
204 <option>kmsg</option>,
205 <option>syslog-or-kmsg</option>,
206 <option>null</option>.</para></listitem>
209 <term><option>--log-level=</option></term>
211 <listitem><para>Set log level. As
212 argument this accepts a numerical log
213 level or the well-known <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
214 symbolic names (lowercase):
215 <option>emerg</option>,
216 <option>alert</option>,
217 <option>crit</option>,
218 <option>err</option>,
219 <option>warning</option>,
220 <option>notice</option>,
221 <option>info</option>,
222 <option>debug</option>.</para></listitem>
225 <term><option>--log-color=</option></term>
227 <listitem><para>Highlight important
228 log messages. Argument is a boolean
229 value. If the argument is omitted it
231 <option>true</option>.</para></listitem>
234 <term><option>--log-location=</option></term>
236 <listitem><para>Include code location
237 in log messages. This is mostly
238 relevant for debugging
239 purposes. Argument is a boolean
240 value. If the argument is omitted
242 <option>true</option>.</para></listitem>
248 <title>Concepts</title>
250 <para>systemd provides a dependency system between
251 various entities called "units". Units encapsulate
252 various objects that are relevant for system boot-up
253 and maintenance. The majority of units are configured
254 in unit configuration files, whose syntax and basic
255 set of options is described in
256 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
257 however some are created automatically from other
258 configuration or dynamically from system state. Units
259 may be 'active' (meaning started, bound, plugged in,
260 ... depending on the unit type, see below), or
261 'inactive' (meaning stopped, unbound, unplugged, ...),
262 as well as in the process of being activated or
263 deactivated, i.e. between the two states (these states
264 are called 'activating', 'deactivating'). A special
265 'failed' state is available as well which is very
266 similar to 'inactive' and is entered when the service
267 failed in some way (process returned error code on
268 exit, or crashed, or an operation timed out). If this
269 state is entered the cause will be logged, for later
270 reference. Note that the various unit types may have a
271 number of additional substates, which are mapped to
272 the five generalized unit states described
275 <para>The following unit types are available:</para>
278 <listitem><para>Service units, which control
279 daemons and the processes they consist of. For
281 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
283 <listitem><para>Socket units, which
284 encapsulate local IPC or network sockets in
285 the system, useful for socket-based
286 activation. For details about socket units see
287 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
288 for details on socket-based activation and
289 other forms of activation, see
290 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
292 <listitem><para>Target units are useful to
293 group units, or provide well-known
294 synchronization points during boot-up, see
295 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
297 <listitem><para>Device units expose kernel
298 devices in systemd and may be used to
299 implement device-based activation. For details
301 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
303 <listitem><para>Mount units control mount
304 points in the file system, for details see
305 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
307 <listitem><para>Automount units provide
308 automount capabilities, for on-demand mounting
309 of file systems as well as parallelized
311 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
313 <listitem><para>Snapshot units can be used to
314 temporarily save the state of the set of
315 systemd units, which later may be restored by
316 activating the saved snapshot unit. For more
318 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
320 <listitem><para>Timer units are useful for
321 triggering activation of other units based on
322 timers. You may find details in
323 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
325 <listitem><para>Swap units are very similar to
326 mount units and encapsulate memory swap
327 partitions or files of the operating
328 system. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
330 <listitem><para>Path units may be used
331 to activate other services when file system
332 objects change or are modified. See
333 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
337 <para>Units are named as their configuration
338 files. Some units have special semantics. A detailed
340 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
342 <para>systemd knows various kinds of dependencies,
343 including positive and negative requirement
344 dependencies (i.e. <varname>Requires=</varname> and
345 <varname>Conflicts=</varname>) as well as ordering
346 dependencies (<varname>After=</varname> and
347 <varname>Before=</varname>). NB: ordering and
348 requirement dependencies are orthogonal. If only a
349 requirement dependency exists between two units
350 (e.g. <filename>foo.service</filename> requires
351 <filename>bar.service</filename>), but no ordering
352 dependency (e.g. <filename>foo.service</filename>
353 after <filename>bar.service</filename>) and both are
354 requested to start, they will be started in
355 parallel. It is a common pattern that both requirement
356 and ordering dependencies are placed between two
357 units. Also note that the majority of dependencies are
358 implicitly created and maintained by systemd. In most
359 cases it should be unnecessary to declare additional
360 dependencies manually, however it is possible to do
363 <para>Application programs and units (via
364 dependencies) may request state changes of units. In
365 systemd, these requests are encapsulated as 'jobs' and
366 maintained in a job queue. Jobs may succeed or can
367 fail, their execution is ordered based on the ordering
368 dependencies of the units they have been scheduled
371 <para>On boot systemd activates the target unit
372 <filename>default.target</filename> whose job is to
373 activate on-boot services and other on-boot units by
374 pulling them in via dependencies. Usually the unit
375 name is just an alias (symlink) for either
376 <filename>graphical.target</filename> (for
377 fully-featured boots into the UI) or
378 <filename>multi-user.target</filename> (for limited
379 console-only boots for use in embedded or server
380 environments, or similar; a subset of
381 graphical.target). However it is at the discretion of
382 the administrator to configure it as an alias to any
383 other target unit. See
384 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
385 for details about these target units.</para>
387 <para>Processes systemd spawns are placed in
388 individual Linux control groups named after the unit
389 which they belong to in the private systemd
390 hierarchy. (see <ulink
391 url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
392 for more information about control groups, or short
393 "cgroups"). systemd uses this to effectively keep
394 track of processes. Control group information is
395 maintained in the kernel, and is accessible via the
396 file system hierarchy (beneath
397 <filename>/sys/fs/cgroup/systemd/</filename>), or in tools
399 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
400 (<command>ps xawf -eo pid,user,cgroup,args</command>
401 is particularly useful to list all processes and the
402 systemd units they belong to.).</para>
404 <para>systemd is compatible with the SysV init system
405 to a large degree: SysV init scripts are supported and
406 simply read as an alternative (though limited)
407 configuration file format. The SysV
408 <filename>/dev/initctl</filename> interface is
409 provided, and compatibility implementations of the
410 various SysV client tools are available. In addition to
411 that, various established Unix functionality such as
412 <filename>/etc/fstab</filename> or the
413 <filename>utmp</filename> database are
416 <para>systemd has a minimal transaction system: if a
417 unit is requested to start up or shut down it will add
418 it and all its dependencies to a temporary
419 transaction. Then, it will verify if the transaction
420 is consistent (i.e. whether the ordering of all units
421 is cycle-free). If it is not, systemd will try to fix
422 it up, and removes non-essential jobs from the
423 transaction that might remove the loop. Also, systemd
424 tries to suppress non-essential jobs in the
425 transaction that would stop a running service. Finally
426 it is checked whether the jobs of the transaction
427 contradict jobs that have already been queued, and
428 optionally the transaction is aborted then. If all
429 worked out and the transaction is consistent and
430 minimized in its impact it is merged with all already
431 outstanding jobs and added to the run
432 queue. Effectively this means that before executing a
433 requested operation, systemd will verify that it makes
434 sense, fixing it if possible, and only failing if it
435 really cannot work.</para>
437 <para>Systemd contains native implementations of
438 various tasks that need to be executed as part of the
439 boot process. For example, it sets the host name or
440 configures the loopback network device. It also sets
441 up and mounts various API file systems, such as
442 <filename>/sys</filename> or
443 <filename>/proc</filename>.</para>
445 <para>For more information about the concepts and
446 ideas behind systemd please refer to the <ulink
447 url="http://0pointer.de/blog/projects/systemd.html">Original
448 Design Document</ulink>.</para>
450 <para>Note that some but not all interfaces provided
451 by systemd are covered by the <ulink
452 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
453 Stability Promise</ulink>.</para>
457 <title>Directories</title>
461 <term>System unit directories</term>
463 <listitem><para>The systemd system
464 manager reads unit configuration from
465 various directories. Packages that
466 want to install unit files shall place
467 them in the directory returned by
468 <command>pkg-config systemd
469 --variable=systemdsystemunitdir</command>. Other
470 directories checked are
471 <filename>/usr/local/share/systemd/system</filename>
473 <filename>/usr/share/systemd/system</filename>. User
474 configuration always takes
475 precedence. <command>pkg-config
477 --variable=systemdsystemconfdir</command>
478 returns the path of the system
479 configuration directory. Packages
480 should alter the content of these
481 directories only with the
482 <command>enable</command> and
483 <command>disable</command> commands of
485 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
486 tool.</para></listitem>
492 <term>Session unit directories</term>
494 <listitem><para>Similar rules apply
496 directories. However, here the <ulink
497 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
498 Base Directory specification</ulink>
500 units. Applications should place their
501 unit files in the directory returned
502 by <command>pkg-config systemd
503 --variable=systemdsessionunitdir</command>. Global
504 configuration is done in the directory
505 reported by <command>pkg-config
507 --variable=systemdsessionconfdir</command>. The
508 <command>enable</command> and
509 <command>disable</command> commands of
511 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
512 tool can handle both global (i.e. for
513 all users) and private (for one user)
514 enabling/disabling of
515 units.</para></listitem>
521 <term>SysV init scripts directory</term>
523 <listitem><para>The location of the
524 SysV init script directory varies
525 between distributions. If systemd
526 cannot find a native unit file for a
527 requested service, it will look for a
528 SysV init script of the same name
530 <filename>.service</filename> suffix
531 removed).</para></listitem>
537 <term>SysV runlevel link farm directory</term>
539 <listitem><para>The location of the
540 SysV runlevel link farm directory
541 varies between distributions. systemd
542 will take the link farm into account
543 when figuring out whether a service
544 shall be enabled. Note that a service
545 unit with a native unit configuration
546 file cannot be started by activating it
547 in the SysV runlevel link
548 farm.</para></listitem>
554 <title>Signals</title>
560 <listitem><para>Upon receiving this
561 signal the systemd system manager
562 serializes its state, reexecutes
563 itself and deserializes the saved
564 state again. This is mostly equivalent
565 to <command>systemctl
566 daemon-reexec</command>.</para>
568 <para>systemd session managers will
570 <filename>exit.target</filename> unit
571 when this signal is received. This is
573 <command>systemctl --session start
574 exit.target</command>.</para></listitem>
580 <listitem><para>Upon receiving this
581 signal the systemd system manager will
583 <filename>ctrl-alt-del.target</filename> unit. This
584 is mostly equivalent to
585 <command>systemctl start
586 ctl-alt-del.target</command>.</para>
588 <para>systemd session managers
589 treat this signal the same way as
590 SIGTERM.</para></listitem>
594 <term>SIGWINCH</term>
596 <listitem><para>When this signal is
597 received the systemd system manager
599 <filename>kbrequest.target</filename>
600 unit. This is mostly equivalent to
601 <command>systemctl start
602 kbrequest.target</command>.</para>
604 <para>This signal is ignored by
606 managers.</para></listitem>
612 <listitem><para>When this signal is
613 received the systemd manager
615 <filename>sigpwr.target</filename>
616 unit. This is mostly equivalent to
617 <command>systemctl start
618 sigpwr.target</command>.</para></listitem>
624 <listitem><para>When this signal is
625 received the systemd manager will try
626 to reconnect to the D-Bus
627 bus.</para></listitem>
633 <listitem><para>When this signal is
634 received the systemd manager will log
635 its complete state in human readable
636 form. The data logged is the same as
637 printed by <command>systemctl
638 dump</command>.</para></listitem>
644 <listitem><para>Reloads the complete
645 daemon configuration. This is mostly
646 equivalent to <command>systemctl
647 daemon-reload</command>.</para></listitem>
651 <term>SIGRTMIN+0</term>
653 <listitem><para>Enters default mode, starts the
654 <filename>default.target</filename>
655 unit. This is mostly equivalent to
656 <command>systemctl start
657 default.target</command>.</para></listitem>
661 <term>SIGRTMIN+1</term>
663 <listitem><para>Enters rescue mode,
665 <filename>rescue.target</filename>
666 unit. This is mostly equivalent to
667 <command>systemctl isolate
668 rescue.target</command>.</para></listitem>
672 <term>SIGRTMIN+2</term>
674 <listitem><para>Enters emergency mode,
676 <filename>emergency.service</filename>
677 unit. This is mostly equivalent to
678 <command>systemctl isolate
679 emergency.service</command>.</para></listitem>
683 <term>SIGRTMIN+3</term>
685 <listitem><para>Halts the machine,
687 <filename>halt.target</filename>
688 unit. This is mostly equivalent to
689 <command>systemctl start
690 halt.target</command>.</para></listitem>
694 <term>SIGRTMIN+4</term>
696 <listitem><para>Powers off the machine,
698 <filename>poweroff.target</filename>
699 unit. This is mostly equivalent to
700 <command>systemctl start
701 poweroff.target</command>.</para></listitem>
705 <term>SIGRTMIN+5</term>
707 <listitem><para>Reboots the machine,
709 <filename>reboot.target</filename>
710 unit. This is mostly equivalent to
711 <command>systemctl start
712 reboot.target</command>.</para></listitem>
718 <title>Environment</title>
722 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
723 <listitem><para>systemd reads the
724 log level from this environment
725 variable. This can be overridden with
726 <option>--log-level=</option>.</para></listitem>
730 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
731 <listitem><para>systemd reads the
732 log target from this environment
733 variable. This can be overridden with
734 <option>--log-target=</option>.</para></listitem>
738 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
739 <listitem><para>Controls whether
740 systemd highlights important log
741 messages. This can be overridden with
742 <option>--log-color=</option>.</para></listitem>
746 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
747 <listitem><para>Controls whether
748 systemd prints the code location along
749 with log messages. This can be
751 <option>--log-location=</option>.</para></listitem>
755 <term><varname>$XDG_CONFIG_HOME</varname></term>
756 <term><varname>$XDG_CONFIG_DIRS</varname></term>
757 <term><varname>$XDG_DATA_HOME</varname></term>
758 <term><varname>$XDG_DATA_DIRS</varname></term>
760 <listitem><para>The systemd session
761 manager uses these variables in
762 accordance to the <ulink
763 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
764 Base Directory specification</ulink>
765 to find its configuration.</para></listitem>
769 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
771 <listitem><para>Controls where systemd
773 files.</para></listitem>
777 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
779 <listitem><para>Controls where systemd
780 looks for SysV init scripts.</para></listitem>
784 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
786 <listitem><para>Controls where systemd
787 looks for SysV init script runlevel link
788 farms.</para></listitem>
792 <term><varname>$LISTEN_PID</varname></term>
793 <term><varname>$LISTEN_FDS</varname></term>
795 <listitem><para>Set by systemd for
796 supervised processes during
797 socket-based activation. See
798 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
799 for more information.
804 <term><varname>$NOTIFY_SOCKET</varname></term>
806 <listitem><para>Set by systemd for
807 supervised processes for status and
808 start-up completion notification. See
809 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
810 for more information.
817 <title>Kernel Command Line</title>
819 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
823 <term><varname>systemd.unit=</varname></term>
825 <listitem><para>Overrides the unit to
826 activate on boot. Defaults to
827 <filename>default.target</filename>. This
828 may be used to temporarily boot into a
829 different boot unit, for example
830 <filename>rescue.target</filename> or
831 <filename>emergency.service</filename>. See
832 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
833 for details about these
834 units.</para></listitem>
838 <term><varname>systemd.dump_core=</varname></term>
840 <listitem><para>Takes a boolean
841 argument. If <option>true</option>
842 systemd dumps core when it
843 crashes. Otherwise no core dump is
845 <option>true</option>.</para></listitem>
849 <term><varname>systemd.crash_shell=</varname></term>
851 <listitem><para>Takes a boolean
852 argument. If <option>true</option>
853 systemd spawns a shell when it
854 crashes. Otherwise no shell is
856 <option>false</option>, for security
857 reasons, as the shell is not protected
859 authentication.</para></listitem>
863 <term><varname>systemd.crash_chvt=</varname></term>
865 <listitem><para>Takes an integer
866 argument. If positive systemd
867 activates the specified virtual
868 terminal when it crashes. Defaults to
869 <literal>-1</literal>.</para></listitem>
873 <term><varname>systemd.confirm_spawn=</varname></term>
875 <listitem><para>Takes a boolean
876 argument. If <option>true</option>
877 asks for confirmation when spawning
878 processes. Defaults to
879 <option>false</option>.</para></listitem>
883 <term><varname>systemd.show_status=</varname></term>
885 <listitem><para>Takes a boolean
886 argument. If <option>true</option>
887 shows terse service status updates on
888 the console during bootup. Defaults to
889 <option>true</option>.</para></listitem>
893 <term><varname>systemd.sysv_console=</varname></term>
895 <listitem><para>Takes a boolean
896 argument. If <option>true</option>
897 output of SysV init scripts will be
898 directed to the console. Defaults to
899 <option>true</option>, unless
900 <option>quiet</option> is passed as
901 kernel command line option in which
903 <option>false</option>.</para></listitem>
907 <term><varname>systemd.log_target=</varname></term>
908 <term><varname>systemd.log_level=</varname></term>
909 <term><varname>systemd.log_color=</varname></term>
910 <term><varname>systemd.log_location=</varname></term>
912 <listitem><para>Controls log output,
913 with the same effect as the
914 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
915 environment variables described above.</para></listitem>
922 <title>Sockets and FIFOs</title>
926 <term><filename>@/org/freedesktop/systemd1/notify</filename></term>
928 <listitem><para>Daemon status
929 notification socket. This is an AF_UNIX
930 datagram socket in the Linux abstract
931 namespace, and is used to implement
932 the daemon notification logic as
934 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
939 <term><filename>@/org/freedesktop/systemd1/logger</filename></term>
941 <listitem><para>Used internally by the
942 <filename>systemd-logger.service</filename>
943 unit to connect STDOUT and/or STDERR
944 of spawned processes to
945 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
946 or the kernel log buffer. This is an
947 AF_UNIX stream socket in the Linux
948 abstract namespace.</para></listitem>
952 <term><filename>@/org/freedesktop/systemd1/shutdown</filename></term>
954 <listitem><para>Used internally by the
955 <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>
956 tool to implement delayed
957 shutdowns. This is an AF_UNIX datagram
958 socket in the Linux abstract
959 namespace.</para></listitem>
963 <term><filename>@/org/freedesktop/systemd1/private</filename></term>
965 <listitem><para>Used internally as
966 communication channel between
967 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
968 and the systemd process. This is an
969 AF_UNIX stream socket in the Linux
970 abstract namespace. This interface is
971 private to systemd and should not be
973 projects.</para></listitem>
977 <term><filename>/dev/initctl</filename></term>
979 <listitem><para>Limited compatibility
980 support for the SysV client interface,
981 as implemented by the
982 <filename>systemd-initctl.service</filename>
983 unit. This is a named pipe in the file
984 system. This interface is obsolete and
985 should not be used in new
986 applications.</para></listitem>
992 <title>See Also</title>
994 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
995 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
996 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
997 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
998 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
999 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1000 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1001 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>