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 'maintenance' 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>/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>
446 <title>Directories</title>
450 <term>System unit directories</term>
452 <listitem><para>The systemd system
453 manager reads unit configuration from
454 various directories. Packages that
455 want to install unit files shall place
456 them in the directory returned by
457 <command>pkg-config systemd
458 --variable=systemdsystemunitdir</command>. Other
459 directories checked are
460 <filename>/usr/local/share/systemd/system</filename>
462 <filename>/usr/share/systemd/system</filename>. User
463 configuration always takes
464 precedence. <command>pkg-config
466 --variable=systemdsystemconfdir</command>
467 returns the path of the system
468 configuration directory. Packages
469 should alter the content of these
470 directories only with the
471 <command>enable</command> and
472 <command>disable</command> commands of
474 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
475 tool.</para></listitem>
481 <term>Session unit directories</term>
483 <listitem><para>Similar rules apply
485 directories. However, here the <ulink
486 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
487 Base Directory specification</ulink>
489 units. Applications should place their
490 unit files in the directory returned
491 by <command>pkg-config systemd
492 --variable=systemdsessionunitdir</command>. Global
493 configuration is done in the directory
494 reported by <command>pkg-config
496 --variable=systemdsessionconfdir</command>. The
497 <command>enable</command> and
498 <command>disable</command> commands of
500 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
501 tool can handle both global (i.e. for
502 all users) and private (for one user)
503 enabling/disabling of
504 units.</para></listitem>
510 <term>SysV init scripts directory</term>
512 <listitem><para>The location of the
513 SysV init script directory varies
514 between distributions. If systemd
515 cannot find a native unit file for a
516 requested service, it will look for a
517 SysV init script of the same name
519 <filename>.service</filename> suffix
520 removed).</para></listitem>
526 <term>SysV runlevel link farm directory</term>
528 <listitem><para>The location of the
529 SysV runlevel link farm directory
530 varies between distributions. systemd
531 will take the link farm into account
532 when figuring out whether a service
533 shall be enabled. Note that a service
534 unit with a native unit configuration
535 file cannot be started by activating it
536 in the SysV runlevel link
537 farm.</para></listitem>
543 <title>Signals</title>
549 <listitem><para>Upon receiving this
550 signal the systemd system manager
551 serializes its state, reexecutes
552 itself and deserializes the saved
553 state again. This is mostly equivalent
554 to <command>systemctl
555 daemon-reexec</command>.</para>
557 <para>systemd session managers will
559 <filename>exit.target</filename> unit
560 when this signal is received. This is
562 <command>systemctl --session start
563 exit.target</command>.</para></listitem>
569 <listitem><para>Upon receiving this
570 signal the systemd system manager will
572 <filename>ctrl-alt-del.target</filename> unit. This
573 is mostly equivalent to
574 <command>systemctl start
575 ctl-alt-del.target</command>.</para>
577 <para>systemd session managers
578 treat this signal the same way as
579 SIGTERM.</para></listitem>
583 <term>SIGWINCH</term>
585 <listitem><para>When this signal is
586 received the systemd system manager
588 <filename>kbrequest.target</filename>
589 unit. This is mostly equivalent to
590 <command>systemctl start
591 kbrequest.target</command>.</para>
593 <para>This signal is ignored by
595 managers.</para></listitem>
601 <listitem><para>When this signal is
602 received the systemd manager
604 <filename>sigpwr.target</filename>
605 unit. This is mostly equivalent to
606 <command>systemctl start
607 sigpwr.target</command>.</para></listitem>
613 <listitem><para>When this signal is
614 received the systemd manager will try
615 to reconnect to the D-Bus
616 bus.</para></listitem>
622 <listitem><para>When this signal is
623 received the systemd manager will log
624 its complete state in human readable
625 form. The data logged is the same as
626 printed by <command>systemctl
627 dump</command>.</para></listitem>
633 <listitem><para>Reloads the complete
634 daemon configuration. This is mostly
635 equivalent to <command>systemctl
636 daemon-reload</command>.</para></listitem>
640 <term>SIGRTMIN+0</term>
642 <listitem><para>Enters default mode, starts the
643 <filename>default.target</filename>
644 unit. This is mostly equivalent to
645 <command>systemctl start
646 default.target</command>.</para></listitem>
650 <term>SIGRTMIN+1</term>
652 <listitem><para>Enters rescue mode,
654 <filename>rescue.target</filename>
655 unit. This is mostly equivalent to
656 <command>systemctl isolate
657 rescue.target</command>.</para></listitem>
661 <term>SIGRTMIN+2</term>
663 <listitem><para>Enters emergency mode,
665 <filename>emergency.service</filename>
666 unit. This is mostly equivalent to
667 <command>systemctl isolate
668 emergency.service</command>.</para></listitem>
672 <term>SIGRTMIN+3</term>
674 <listitem><para>Halts the machine,
676 <filename>halt.target</filename>
677 unit. This is mostly equivalent to
678 <command>systemctl start
679 halt.target</command>.</para></listitem>
683 <term>SIGRTMIN+4</term>
685 <listitem><para>Powers off the machine,
687 <filename>poweroff.target</filename>
688 unit. This is mostly equivalent to
689 <command>systemctl start
690 poweroff.target</command>.</para></listitem>
694 <term>SIGRTMIN+5</term>
696 <listitem><para>Reboots the machine,
698 <filename>reboot.target</filename>
699 unit. This is mostly equivalent to
700 <command>systemctl start
701 reboot.target</command>.</para></listitem>
707 <title>Environment</title>
711 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
712 <listitem><para>systemd reads the
713 log level from this environment
714 variable. This can be overridden with
715 <option>--log-level=</option>.</para></listitem>
719 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
720 <listitem><para>systemd reads the
721 log target from this environment
722 variable. This can be overridden with
723 <option>--log-target=</option>.</para></listitem>
727 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
728 <listitem><para>Controls whether
729 systemd highlights important log
730 messages. This can be overridden with
731 <option>--log-color=</option>.</para></listitem>
735 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
736 <listitem><para>Controls whether
737 systemd prints the code location along
738 with log messages. This can be
740 <option>--log-location=</option>.</para></listitem>
744 <term><varname>$XDG_CONFIG_HOME</varname></term>
745 <term><varname>$XDG_CONFIG_DIRS</varname></term>
746 <term><varname>$XDG_DATA_HOME</varname></term>
747 <term><varname>$XDG_DATA_DIRS</varname></term>
749 <listitem><para>The systemd session
750 manager uses these variables in
751 accordance to the <ulink
752 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
753 Base Directory specification</ulink>
754 to find its configuration.</para></listitem>
758 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
760 <listitem><para>Controls where systemd
762 files.</para></listitem>
766 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
768 <listitem><para>Controls where systemd
769 looks for SysV init scripts.</para></listitem>
773 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
775 <listitem><para>Controls where systemd
776 looks for SysV init script runlevel link
777 farms.</para></listitem>
781 <term><varname>$LISTEN_PID</varname></term>
782 <term><varname>$LISTEN_FDS</varname></term>
784 <listitem><para>Set by systemd for
785 supervised processes during
786 socket-based activation. See
787 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
788 for more information.
793 <term><varname>$NOTIFY_SOCKET</varname></term>
795 <listitem><para>Set by systemd for
796 supervised processes for status and
797 start-up completion notification. See
798 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
799 for more information.
806 <title>Kernel Command Line</title>
808 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
812 <term><varname>systemd.unit=</varname></term>
814 <listitem><para>Overrides the unit to
815 activate on boot. Defaults to
816 <filename>default.target</filename>. This
817 may be used to temporarily boot into a
818 different boot unit, for example
819 <filename>rescue.target</filename> or
820 <filename>emergency.service</filename>. See
821 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
822 for details about these
823 units.</para></listitem>
827 <term><varname>systemd.dump_core=</varname></term>
829 <listitem><para>Takes a boolean
830 argument. If <option>true</option>
831 systemd dumps core when it
832 crashes. Otherwise no core dump is
834 <option>true</option>.</para></listitem>
838 <term><varname>systemd.crash_shell=</varname></term>
840 <listitem><para>Takes a boolean
841 argument. If <option>true</option>
842 systemd spawns a shell when it
843 crashes. Otherwise no core dump is
845 <option>false</option>, for security
846 reasons, as the shell is not protected
848 authentication.</para></listitem>
852 <term><varname>systemd.crash_chvt=</varname></term>
854 <listitem><para>Takes an integer
855 argument. If positive systemd
856 activates the specified virtual
857 terminal when it crashes. Defaults to
858 <literal>-1</literal>.</para></listitem>
862 <term><varname>systemd.confirm_spawn=</varname></term>
864 <listitem><para>Takes a boolean
865 argument. If <option>true</option>
866 asks for confirmation when spawning
867 processes. Defaults to
868 <option>false</option>.</para></listitem>
872 <term><varname>systemd.show_status=</varname></term>
874 <listitem><para>Takes a boolean
875 argument. If <option>true</option>
876 shows terse service status updates on
877 the console during bootup. Defaults to
878 <option>true</option>.</para></listitem>
882 <term><varname>systemd.sysv_console=</varname></term>
884 <listitem><para>Takes a boolean
885 argument. If <option>true</option>
886 output of SysV init scripts will be
887 directed to the console. Defaults to
888 <option>true</option>, unless
889 <option>quiet</option> is passed as
890 kernel command line option in which
892 <option>false</option>.</para></listitem>
896 <term><varname>systemd.log_target=</varname></term>
897 <term><varname>systemd.log_level=</varname></term>
898 <term><varname>systemd.log_color=</varname></term>
899 <term><varname>systemd.log_location=</varname></term>
901 <listitem><para>Controls log output,
902 with the same effect as the
903 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
904 environment variables described above.</para></listitem>
911 <title>Sockets and FIFOs</title>
915 <term><filename>@/org/freedesktop/systemd1/notify</filename></term>
917 <listitem><para>Daemon status
918 notification socket. This is an AF_UNIX
919 datagram socket in the Linux abstract
920 namespace, and is used to implement
921 the daemon notification logic as
923 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
928 <term><filename>@/org/freedesktop/systemd1/logger</filename></term>
930 <listitem><para>Used internally by the
931 <filename>systemd-logger.service</filename>
932 unit to connect STDOUT and/or STDERR
933 of spawned processes to
934 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
935 or the kernel log buffer. This is an
936 AF_UNIX stream socket in the Linux
937 abstract namespace.</para></listitem>
941 <term><filename>@/org/freedesktop/systemd1/shutdown</filename></term>
943 <listitem><para>Used internally by the
944 <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>
945 tool to implement delayed
946 shutdowns. This is an AF_UNIX datagram
947 socket in the Linux abstract
948 namespace.</para></listitem>
952 <term><filename>@/org/freedesktop/systemd1/private</filename></term>
954 <listitem><para>Used internally as
955 communication channel between
956 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
957 and the systemd process. This is an
958 AF_UNIX stream socket in the Linux
959 abstract namespace. This interface is
960 private to systemd and should not be
962 projects.</para></listitem>
966 <term><filename>/dev/initctl</filename></term>
968 <listitem><para>Limited compatibility
969 support for the SysV client interface,
970 as implemented by the
971 <filename>systemd-initctl.service</filename>
972 unit. This is a named pipe in the file
973 system. This interface is obsolete and
974 should not be used in new
975 applications.</para></listitem>
981 <title>See Also</title>
983 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
984 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
985 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
986 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
987 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
988 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
989 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
990 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>