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 not
145 (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
151 debugging.</para></listitem>
154 <term><option>--dump-core</option></term>
156 <listitem><para>Dump core on crash. This switch has no effect when run as session instance.</para></listitem>
159 <term><option>--crash-shell</option></term>
161 <listitem><para>Run shell on crash. This switch has no effect when run as session instance.</para></listitem>
164 <term><option>--confirm-spawn</option></term>
166 <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as session instance.</para></listitem>
169 <term><option>--show-status=</option></term>
171 <listitem><para>Show terse service
172 status information while booting. This
173 switch has no effect when run as
174 session instance. Takes a boolean
175 argument which may be omitted
176 which is interpreted as
177 <option>true</option>.</para></listitem>
180 <term><option>--sysv-console=</option></term>
182 <listitem><para>Controls whether
183 output of SysV init scripts will be
184 directed to the console. This switch
185 has no effect when run as session
186 instance. Takes a boolean argument
187 which may be omitted which is
189 <option>true</option>.</para></listitem>
192 <term><option>--log-target=</option></term>
194 <listitem><para>Set log
195 target. Argument must be one of
196 <option>console</option>,
197 <option>syslog</option>,
198 <option>kmsg</option>,
199 <option>syslog-or-kmsg</option>,
200 <option>null</option>.</para></listitem>
203 <term><option>--log-level=</option></term>
205 <listitem><para>Set log level. As
206 argument this accepts a numerical log
207 level or the well-known <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
208 symbolic names (lowercase):
209 <option>emerg</option>,
210 <option>alert</option>,
211 <option>crit</option>,
212 <option>err</option>,
213 <option>warning</option>,
214 <option>notice</option>,
215 <option>info</option>,
216 <option>debug</option>.</para></listitem>
219 <term><option>--log-color=</option></term>
221 <listitem><para>Highlight important
222 log messages. Argument is a boolean
223 value. If the argument is omitted it
225 <option>true</option>.</para></listitem>
228 <term><option>--log-location=</option></term>
230 <listitem><para>Include code location
231 in log messages. This is mostly
232 relevant for debugging
233 purposes. Argument is a boolean
234 value. If the argument is omitted
236 <option>true</option>.</para></listitem>
242 <title>Concepts</title>
244 <para>systemd provides a dependency system between
245 various entities called "units". Units encapsulate
246 various objects that are relevant for system boot-up
247 and maintenance. The majority of units are configured
248 in unit configuration files, whose syntax and basic
249 set of options is described in
250 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
251 however some are created automatically from other
252 configuration or dynamically from system state. Units
253 may be 'active' (meaning started, bound, plugged in,
254 ... depending on the unit type, see below), or
255 'inactive' (meaning stopped, unbound, unplugged, ...),
256 as well as in the process of being activated or
257 deactivated, i.e. between the two states (these states
258 are called 'activating', 'deactivating'). A special
259 'failed' state is available as well which is very
260 similar to 'inactive' and is entered when the service
261 failed in some way (process returned error code on
262 exit, or crashed, or an operation timed out). If this
263 state is entered the cause will be logged, for later
264 reference. Note that the various unit types may have a
265 number of additional substates, which are mapped to
266 the five generalized unit states described
269 <para>The following unit types are available:</para>
272 <listitem><para>Service units, which control
273 daemons and the processes they consist of. For
275 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
277 <listitem><para>Socket units, which
278 encapsulate local IPC or network sockets in
279 the system, useful for socket-based
280 activation. For details about socket units see
281 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
282 for details on socket-based activation and
283 other forms of activation, see
284 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
286 <listitem><para>Target units are useful to
287 group units, or provide well-known
288 synchronization points during boot-up, see
289 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
291 <listitem><para>Device units expose kernel
292 devices in systemd and may be used to
293 implement device-based activation. For details
295 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
297 <listitem><para>Mount units control mount
298 points in the file system, for details see
299 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
301 <listitem><para>Automount units provide
302 automount capabilities, for on-demand mounting
303 of file systems as well as parallelized
305 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
307 <listitem><para>Snapshot units can be used to
308 temporarily save the state of the set of
309 systemd units, which later may be restored by
310 activating the saved snapshot unit. For more
312 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
314 <listitem><para>Timer units are useful for
315 triggering activation of other units based on
316 timers. You may find details in
317 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
319 <listitem><para>Swap units are very similar to
320 mount units and encapsulated memory swap
321 partitions or files of the operating
322 systemd. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
324 <listitem><para>Path units may be used
325 to activate other services when file system
326 objects change or are modified. See
327 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
331 <para>Units are named as their configuration
332 files. Some units have special semantics. A detailed
334 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
336 <para>systemd knows various kinds of dependencies,
337 including positive and negative requirement
338 dependencies (i.e. <varname>Requires=</varname> and
339 <varname>Conflicts=</varname>) as well as ordering
340 dependencies (<varname>After=</varname> and
341 <varname>Before=</varname>). NB: ordering and
342 requirement dependencies are orthogonal. If only a
343 requirement dependency exists between two units
344 (e.g. <filename>foo.service</filename> requires
345 <filename>bar.service</filename>), but no ordering
346 dependency (e.g. <filename>foo.service</filename>
347 after <filename>bar.service</filename>) and both are
348 requested to start, they will be started in
349 parallel. It is a common pattern that both requirement
350 and ordering dependencies are placed between two
351 units. Also note that the majority of dependencies are
352 implicitly created and maintained by systemd. In most
353 cases it should be unnecessary to declare additional
354 dependencies manually, however it is possible to do
357 <para>Application programs and units (via
358 dependencies) may requests state changes of units. In
359 systemd, these requests are encapsulated as 'jobs' and
360 maintained in a job queue. Jobs may succeed or can
361 fail, their execution is ordered based on the ordering
362 dependencies of the units they have been scheduled
365 <para>On boot systemd activates the target unit
366 <filename>default.target</filename> whose job is to
367 activate on-boot services and other on-boot units by
368 pulling them in via dependencies. Usually the unit
369 name is just an alias (symlink) for either
370 <filename>graphical.target</filename> (for
371 fully-featured boots into the UI) or
372 <filename>multi-user.target</filename> (for limited
373 console-only boots for use in embedded or server
374 environments, or similar; a subset of
375 graphical.target). However it is at the discretion of
376 the administrator to configure it as an alias to any
377 other target unit. See
378 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
379 for details about these target units.</para>
381 <para>Processes systemd spawns are placed in
382 individual Linux control groups named after the unit
383 which they belong to in the private systemd
384 hierarchy. (see <ulink
385 url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
386 for more information about control groups, or short
387 "cgroups"). systemd uses this to effectively keep
388 track of processes. Control group information is
389 maintained in the kernel, and is accessible via the
390 file system hierarchy (beneath
391 <filename>/sys/fs/cgroup/systemd/</filename>), or in tools
393 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
394 (<command>ps xawf -eo pid,user,cgroup,args</command>
395 is particularly useful to list all processes and the
396 systemd units they belong to.).</para>
398 <para>systemd is compatible with the SysV init system
399 to a large degree: SysV init scripts are supported and
400 simply read as an alternative (though limited)
401 configuration file format. The SysV
402 <filename>/dev/initctl</filename> interface is
403 provided, and compatibility implementations of the
404 various SysV client tools are available. In addition to
405 that, various established Unix functionality such as
406 <filename>/etc/fstab</filename> or the
407 <filename>utmp</filename> database are
410 <para>systemd has a minimal transaction system: if a
411 unit is requested to start up or shut down it will add
412 it and all its dependencies to a temporary
413 transaction. Then, it will verify if the transaction
414 is consistent (i.e. whether the ordering of all units
415 is cycle-free). If it is not, systemd will try to fix
416 it up, and removes non-essential jobs from the
417 transaction that might remove the loop. Also, systemd
418 tries to suppress non-essential jobs in the
419 transaction that would stop a running service. Finally
420 it is checked whether the jobs of the transaction
421 contradict jobs that have already been queued, and
422 optionally the transaction is aborted then. If all
423 worked out and the transaction is consistent and
424 minimized in its impact it is merged with all already
425 outstanding jobs and added to the run
426 queue. Effectively this means that before executing a
427 requested operation, systemd will verify that it makes
428 sense, fixing it if possible, and only failing if it
429 really cannot work.</para>
431 <para>Systemd contains native implementations of
432 various tasks that need to be executed as part of the
433 boot process. For example, it sets the host name or
434 configures the loopback network device. It also sets
435 up and mounts various API file systems, such as
436 <filename>/sys</filename> or
437 <filename>/proc</filename>.</para>
439 <para>For more information about the concepts and
440 ideas behind systemd please refer to the <ulink
441 url="http://0pointer.de/blog/projects/systemd.html">Original
442 Design Document</ulink>.</para>
444 <para>Note that some but not all interfaces provided
445 by systemd are covered by the <ulink
446 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
447 Stability Promise</ulink>.</para>
451 <title>Directories</title>
455 <term>System unit directories</term>
457 <listitem><para>The systemd system
458 manager reads unit configuration from
459 various directories. Packages that
460 want to install unit files shall place
461 them in the directory returned by
462 <command>pkg-config systemd
463 --variable=systemdsystemunitdir</command>. Other
464 directories checked are
465 <filename>/usr/local/share/systemd/system</filename>
467 <filename>/usr/share/systemd/system</filename>. User
468 configuration always takes
469 precedence. <command>pkg-config
471 --variable=systemdsystemconfdir</command>
472 returns the path of the system
473 configuration directory. Packages
474 should alter the content of these
475 directories only with the
476 <command>enable</command> and
477 <command>disable</command> commands of
479 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
480 tool.</para></listitem>
486 <term>Session unit directories</term>
488 <listitem><para>Similar rules apply
490 directories. However, here the <ulink
491 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
492 Base Directory specification</ulink>
494 units. Applications should place their
495 unit files in the directory returned
496 by <command>pkg-config systemd
497 --variable=systemdsessionunitdir</command>. Global
498 configuration is done in the directory
499 reported by <command>pkg-config
501 --variable=systemdsessionconfdir</command>. The
502 <command>enable</command> and
503 <command>disable</command> commands of
505 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
506 tool can handle both global (i.e. for
507 all users) and private (for one user)
508 enabling/disabling of
509 units.</para></listitem>
515 <term>SysV init scripts directory</term>
517 <listitem><para>The location of the
518 SysV init script directory varies
519 between distributions. If systemd
520 cannot find a native unit file for a
521 requested service, it will look for a
522 SysV init script of the same name
524 <filename>.service</filename> suffix
525 removed).</para></listitem>
531 <term>SysV runlevel link farm directory</term>
533 <listitem><para>The location of the
534 SysV runlevel link farm directory
535 varies between distributions. systemd
536 will take the link farm into account
537 when figuring out whether a service
538 shall be enabled. Note that a service
539 unit with a native unit configuration
540 file cannot be started by activating it
541 in the SysV runlevel link
542 farm.</para></listitem>
548 <title>Signals</title>
554 <listitem><para>Upon receiving this
555 signal the systemd system manager
556 serializes its state, reexecutes
557 itself and deserializes the saved
558 state again. This is mostly equivalent
559 to <command>systemctl
560 daemon-reexec</command>.</para>
562 <para>systemd session managers will
564 <filename>exit.target</filename> unit
565 when this signal is received. This is
567 <command>systemctl --session start
568 exit.target</command>.</para></listitem>
574 <listitem><para>Upon receiving this
575 signal the systemd system manager will
577 <filename>ctrl-alt-del.target</filename> unit. This
578 is mostly equivalent to
579 <command>systemctl start
580 ctl-alt-del.target</command>.</para>
582 <para>systemd session managers
583 treat this signal the same way as
584 SIGTERM.</para></listitem>
588 <term>SIGWINCH</term>
590 <listitem><para>When this signal is
591 received the systemd system manager
593 <filename>kbrequest.target</filename>
594 unit. This is mostly equivalent to
595 <command>systemctl start
596 kbrequest.target</command>.</para>
598 <para>This signal is ignored by
600 managers.</para></listitem>
606 <listitem><para>When this signal is
607 received the systemd manager
609 <filename>sigpwr.target</filename>
610 unit. This is mostly equivalent to
611 <command>systemctl start
612 sigpwr.target</command>.</para></listitem>
618 <listitem><para>When this signal is
619 received the systemd manager will try
620 to reconnect to the D-Bus
621 bus.</para></listitem>
627 <listitem><para>When this signal is
628 received the systemd manager will log
629 its complete state in human readable
630 form. The data logged is the same as
631 printed by <command>systemctl
632 dump</command>.</para></listitem>
638 <listitem><para>Reloads the complete
639 daemon configuration. This is mostly
640 equivalent to <command>systemctl
641 daemon-reload</command>.</para></listitem>
645 <term>SIGRTMIN+0</term>
647 <listitem><para>Enters default mode, starts the
648 <filename>default.target</filename>
649 unit. This is mostly equivalent to
650 <command>systemctl start
651 default.target</command>.</para></listitem>
655 <term>SIGRTMIN+1</term>
657 <listitem><para>Enters rescue mode,
659 <filename>rescue.target</filename>
660 unit. This is mostly equivalent to
661 <command>systemctl isolate
662 rescue.target</command>.</para></listitem>
666 <term>SIGRTMIN+2</term>
668 <listitem><para>Enters emergency mode,
670 <filename>emergency.service</filename>
671 unit. This is mostly equivalent to
672 <command>systemctl isolate
673 emergency.service</command>.</para></listitem>
677 <term>SIGRTMIN+3</term>
679 <listitem><para>Halts the machine,
681 <filename>halt.target</filename>
682 unit. This is mostly equivalent to
683 <command>systemctl start
684 halt.target</command>.</para></listitem>
688 <term>SIGRTMIN+4</term>
690 <listitem><para>Powers off the machine,
692 <filename>poweroff.target</filename>
693 unit. This is mostly equivalent to
694 <command>systemctl start
695 poweroff.target</command>.</para></listitem>
699 <term>SIGRTMIN+5</term>
701 <listitem><para>Reboots the machine,
703 <filename>reboot.target</filename>
704 unit. This is mostly equivalent to
705 <command>systemctl start
706 reboot.target</command>.</para></listitem>
712 <title>Environment</title>
716 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
717 <listitem><para>systemd reads the
718 log level from this environment
719 variable. This can be overridden with
720 <option>--log-level=</option>.</para></listitem>
724 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
725 <listitem><para>systemd reads the
726 log target from this environment
727 variable. This can be overridden with
728 <option>--log-target=</option>.</para></listitem>
732 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
733 <listitem><para>Controls whether
734 systemd highlights important log
735 messages. This can be overridden with
736 <option>--log-color=</option>.</para></listitem>
740 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
741 <listitem><para>Controls whether
742 systemd prints the code location along
743 with log messages. This can be
745 <option>--log-location=</option>.</para></listitem>
749 <term><varname>$XDG_CONFIG_HOME</varname></term>
750 <term><varname>$XDG_CONFIG_DIRS</varname></term>
751 <term><varname>$XDG_DATA_HOME</varname></term>
752 <term><varname>$XDG_DATA_DIRS</varname></term>
754 <listitem><para>The systemd session
755 manager uses these variables in
756 accordance to the <ulink
757 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
758 Base Directory specification</ulink>
759 to find its configuration.</para></listitem>
763 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
765 <listitem><para>Controls where systemd
767 files.</para></listitem>
771 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
773 <listitem><para>Controls where systemd
774 looks for SysV init scripts.</para></listitem>
778 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
780 <listitem><para>Controls where systemd
781 looks for SysV init script runlevel link
782 farms.</para></listitem>
786 <term><varname>$LISTEN_PID</varname></term>
787 <term><varname>$LISTEN_FDS</varname></term>
789 <listitem><para>Set by systemd for
790 supervised processes during
791 socket-based activation. See
792 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
793 for more information.
798 <term><varname>$NOTIFY_SOCKET</varname></term>
800 <listitem><para>Set by systemd for
801 supervised processes for status and
802 start-up completion notification. See
803 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
804 for more information.
811 <title>Kernel Command Line</title>
813 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
817 <term><varname>systemd.unit=</varname></term>
819 <listitem><para>Overrides the unit to
820 activate on boot. Defaults to
821 <filename>default.target</filename>. This
822 may be used to temporarily boot into a
823 different boot unit, for example
824 <filename>rescue.target</filename> or
825 <filename>emergency.service</filename>. See
826 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
827 for details about these
828 units.</para></listitem>
832 <term><varname>systemd.dump_core=</varname></term>
834 <listitem><para>Takes a boolean
835 argument. If <option>true</option>
836 systemd dumps core when it
837 crashes. Otherwise no core dump is
839 <option>true</option>.</para></listitem>
843 <term><varname>systemd.crash_shell=</varname></term>
845 <listitem><para>Takes a boolean
846 argument. If <option>true</option>
847 systemd spawns a shell when it
848 crashes. Otherwise no core dump is
850 <option>false</option>, for security
851 reasons, as the shell is not protected
853 authentication.</para></listitem>
857 <term><varname>systemd.crash_chvt=</varname></term>
859 <listitem><para>Takes an integer
860 argument. If positive systemd
861 activates the specified virtual
862 terminal when it crashes. Defaults to
863 <literal>-1</literal>.</para></listitem>
867 <term><varname>systemd.confirm_spawn=</varname></term>
869 <listitem><para>Takes a boolean
870 argument. If <option>true</option>
871 asks for confirmation when spawning
872 processes. Defaults to
873 <option>false</option>.</para></listitem>
877 <term><varname>systemd.show_status=</varname></term>
879 <listitem><para>Takes a boolean
880 argument. If <option>true</option>
881 shows terse service status updates on
882 the console during bootup. Defaults to
883 <option>true</option>.</para></listitem>
887 <term><varname>systemd.sysv_console=</varname></term>
889 <listitem><para>Takes a boolean
890 argument. If <option>true</option>
891 output of SysV init scripts will be
892 directed to the console. Defaults to
893 <option>true</option>, unless
894 <option>quiet</option> is passed as
895 kernel command line option in which
897 <option>false</option>.</para></listitem>
901 <term><varname>systemd.log_target=</varname></term>
902 <term><varname>systemd.log_level=</varname></term>
903 <term><varname>systemd.log_color=</varname></term>
904 <term><varname>systemd.log_location=</varname></term>
906 <listitem><para>Controls log output,
907 with the same effect as the
908 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
909 environment variables described above.</para></listitem>
916 <title>Sockets and FIFOs</title>
920 <term><filename>@/org/freedesktop/systemd1/notify</filename></term>
922 <listitem><para>Daemon status
923 notification socket. This is an AF_UNIX
924 datagram socket in the Linux abstract
925 namespace, and is used to implement
926 the daemon notification logic as
928 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
933 <term><filename>@/org/freedesktop/systemd1/logger</filename></term>
935 <listitem><para>Used internally by the
936 <filename>systemd-logger.service</filename>
937 unit to connect STDOUT and/or STDERR
938 of spawned processes to
939 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
940 or the kernel log buffer. This is an
941 AF_UNIX stream socket in the Linux
942 abstract namespace.</para></listitem>
946 <term><filename>@/org/freedesktop/systemd1/shutdown</filename></term>
948 <listitem><para>Used internally by the
949 <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>
950 tool to implement delayed
951 shutdowns. This is an AF_UNIX datagram
952 socket in the Linux abstract
953 namespace.</para></listitem>
957 <term><filename>@/org/freedesktop/systemd1/private</filename></term>
959 <listitem><para>Used internally as
960 communication channel between
961 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
962 and the systemd process. This is an
963 AF_UNIX stream socket in the Linux
964 abstract namespace. This interface is
965 private to systemd and should not be
967 projects.</para></listitem>
971 <term><filename>/dev/initctl</filename></term>
973 <listitem><para>Limited compatibility
974 support for the SysV client interface,
975 as implemented by the
976 <filename>systemd-initctl.service</filename>
977 unit. This is a named pipe in the file
978 system. This interface is obsolete and
979 should not be used in new
980 applications.</para></listitem>
986 <title>See Also</title>
988 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
989 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
990 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
991 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
992 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
993 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
994 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
995 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>