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 status information while booting. This switch has no effect when run as session instance.</para></listitem>
174 <term><option>--log-target=</option></term>
176 <listitem><para>Set log
177 target. Argument must be one of
178 <option>console</option>,
179 <option>syslog</option>,
180 <option>kmsg</option>,
181 <option>syslog-or-kmsg</option>,
182 <option>null</option>.</para></listitem>
185 <term><option>--log-level=</option></term>
187 <listitem><para>Set log level. As
188 argument this accepts a numerical log
189 level or the well-known <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
190 symbolic names (lowercase):
191 <option>emerg</option>,
192 <option>alert</option>,
193 <option>crit</option>,
194 <option>err</option>,
195 <option>warning</option>,
196 <option>notice</option>,
197 <option>info</option>,
198 <option>debug</option>.</para></listitem>
201 <term><option>--log-color=</option></term>
203 <listitem><para>Highlight important
204 log messages. Argument is a boolean
205 value. If the argument is omitted it
207 <option>true</option>.</para></listitem>
210 <term><option>--log-location=</option></term>
212 <listitem><para>Include code location
213 in log messages. This is mostly
214 relevant for debugging
215 purposes. Argument is a boolean
216 value. If the argument is omitted
218 <option>true</option>.</para></listitem>
224 <title>Concepts</title>
226 <para>systemd provides a dependency system between
227 various entities called "units". Units encapsulate
228 various objects that are relevant for system boot-up
229 and maintainance. The majority of units are configured
230 in unit configuration files, whose syntax and basic
231 set of options is described in
232 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
233 however some are created automatically from other
234 configuration or dynamically from system state. Units
235 may be 'active' (meaning started, bound, plugged in,
236 ... depending on the unit type, see below), or
237 'inactive' (meaning stopped, unbound, unplugged, ...),
238 as well as in the process of being activated or
239 deactivated, i.e. between the two states (these states
240 are called 'activating', 'deactivating'). A special
241 'maintenance' state is available as well which is very
242 similar to 'inactive' and is entered when the service
243 failed in some way (process returned error code on
244 exit, or crashed, or an operation timed out). If this
245 state is entered the cause will be logged, for later
246 reference. Note that the various unit types may have a
247 number of additional substates, which are mapped to
248 the five generalized unit states described
251 <para>The following unit types are available:</para>
254 <listitem><para>Service units, which control
255 daemons and the processes they consist of. For
257 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
259 <listitem><para>Socket units, which
260 encapsulate local IPC or network sockets in
261 the system, useful for socket-based
262 activation. For details about socket units see
263 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
264 for details on socket-based activation and
265 other forms of activation, see
266 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
268 <listitem><para>Target units are useful to
269 group units, or provide well-known
270 synchronization points during boot-up, see
271 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
273 <listitem><para>Device units expose kernel
274 devices in systemd and may be used to
275 implement device-based activation. For details
277 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
279 <listitem><para>Mount units control mount
280 points in the file system, for details see
281 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
283 <listitem><para>Automount units provide
284 automount capabilities, for on-demand mounting
285 of file systems as well as parallelized
287 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
289 <listitem><para>Snapshot units can be used to
290 temporarily save the state of the set of
291 systemd units, which later may be restored by
292 activating the saved snapshot unit. For more
294 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
296 <listitem><para>Timer units are useful for
297 triggering activation of other units based on
298 timers. You may find details in
299 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
301 <listitem><para>Swap units are very similar to
302 mount units and encapsulated memory swap
303 partitions or files of the operating
304 systemd. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
306 <listitem><para>Path units may be used
307 to activate other services when file system
308 objects change or are modified. See
309 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
313 <para>Units are named as their configuration
314 files. Some units have special semantics. A detailed
316 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
318 <para>systemd knows various kinds of dependencies,
319 including positive and negative requirement
320 dependencies (i.e. <varname>Requires=</varname> and
321 <varname>Conflicts=</varname>) as well as ordering
322 dependencies (<varname>After=</varname> and
323 <varname>Before=</varname>). NB: ordering and
324 requirement dependencies are orthogonal. If only a
325 requirement dependency exists between two units
326 (e.g. <filename>foo.service</filename> requires
327 <filename>bar.service</filename>), but no ordering
328 dependency (e.g. <filename>foo.service</filename>
329 after <filename>bar.service</filename>) and both are
330 requested to start, they will be started in
331 parallel. It is a common pattern that both requirement
332 and ordering dependencies are placed between two
333 units. Also note that the majority of dependencies are
334 implicitly created and maintained by systemd. In most
335 cases it should be unnecessary to declare additional
336 dependencies manually, however it is possible to do
339 <para>Application programs and units (via
340 dependencies) may requests state changes of units. In
341 systemd, these requests are encapsulated as 'jobs' and
342 maintained in a job queue. Jobs may succeed or can
343 fail, their execution is ordered based on the ordering
344 dependencies of the units they have been scheduled
347 <para>On boot systemd activates the target unit
348 <filename>default.target</filename> whose job is to
349 activate on-boot services and other on-boot units by
350 pulling them in via dependencies. Usually the unit
351 name is just an alias (symlink) for either
352 <filename>graphical.target</filename> (for
353 fully-featured boots into the UI) or
354 <filename>multi-user.target</filename> (for limited
355 console-only boots for use in embedded or server
356 environments, or similar; a subset of
357 graphical.target). However it is at the discretion of
358 the administrator to configure it as an alias to any
359 other target unit. See
360 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
361 for details about these target units.</para>
363 <para>Processes systemd spawns are placed in
364 individual Linux control groups named after the unit
365 which they belong to in the private systemd
366 hierarchy. (see <ulink
367 url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
368 for more information about control groups, or short
369 "cgroups"). systemd uses this to effectively keep
370 track of processes. Control group information is
371 maintained in the kernel, and is accessible via the
372 file system hierarchy (beneath
373 <filename>/cgroup/systemd/</filename>), or in tools
375 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
376 (<command>ps xawf -eo pid,user,cgroup,args</command>
377 is particularly useful to list all processes and the
378 systemd units they belong to.).</para>
380 <para>systemd is compatible with the SysV init system
381 to a large degree: SysV init scripts are supported and
382 simply read as an alternative (though limited)
383 configuration file format. The SysV
384 <filename>/dev/initctl</filename> interface is
385 provided, and compatibility implementations of the
386 various SysV client tools are available. In addition to
387 that, various established Unix functionality such as
388 <filename>/etc/fstab</filename> or the
389 <filename>utmp</filename> database are
392 <para>systemd has a minimal transaction system: if a
393 unit is requested to start up or shut down it will add
394 it and all its dependencies to a temporary
395 transaction. Then, it will verify if the transaction
396 is consistent (i.e. whether the ordering of all units
397 is cycle-free). If it is not, systemd will try to fix
398 it up, and removes non-essential jobs from the
399 transaction that might remove the loop. Also, systemd
400 tries to suppress non-essential jobs in the
401 transaction that would stop a running service. Finally
402 it is checked whether the jobs of the transaction
403 contradict jobs that have already been queued, and
404 optionally the transaction is aborted then. If all
405 worked out and the transaction is consistent and
406 minimized in its impact it is merged with all already
407 outstanding jobs and added to the run
408 queue. Effectively this means that before executing a
409 requested operation, systemd will verify that it makes
410 sense, fixing it if possible, and only failing if it
411 really cannot work.</para>
413 <para>Systemd contains native implementations of
414 various tasks that need to be executed as part of the
415 boot process. For example, it sets the host name or
416 configures the loopback network device. It also sets
417 up and mounts various API file systems, such as
418 <filename>/sys</filename> or
419 <filename>/proc</filename>.</para>
421 <para>For more information about the concepts and
422 ideas behind systemd please refer to the <ulink
423 url="http://0pointer.de/blog/projects/systemd.html">Original
424 Design Document</ulink>.</para>
428 <title>Directories</title>
432 <term>System unit directories</term>
434 <listitem><para>The systemd system
435 manager reads unit configuration from
436 various directories. Packages that
437 want to install unit files shall place
438 them in the directory returned by
439 <command>pkg-config systemd
440 --variable=systemdsystemunitdir</command>. Other
441 directories checked are
442 <filename>/usr/local/share/systemd/system</filename>
444 <filename>/usr/share/systemd/system</filename>. User
445 configuration always takes
446 precedence. <command>pkg-config
448 --variable=systemdsystemconfdir</command>
449 returns the path of the system
450 configuration directory. Packages
451 should alter the content of these directories
453 <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
454 tool.</para></listitem>
460 <term>Session unit directories</term>
462 <listitem><para>Similar rules apply
464 directories. However, here the <ulink
465 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
466 Base Directory specification</ulink>
468 units. Applications should place their
469 unit files in the directory returned
470 by <command>pkg-config systemd
471 --variable=systemdsessionunitdir</command>. Global
472 configuration is done in the
473 directory reported by
474 <command>pkg-config systemd
475 --variable=systemdsessionconfdir</command>. The
476 <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
477 tool can handle both global (i.e. for
478 all users) and private (for one user)
479 enabling/disabling of
480 units.</para></listitem>
486 <term>SysV init scripts directory</term>
488 <listitem><para>The location of the
489 SysV init script directory varies
490 between distributions. If systemd
491 cannot find a native unit file for a
492 requested service, it will look for a
493 SysV init script of the same name
495 <filename>.service</filename> suffix
496 removed).</para></listitem>
502 <term>SysV runlevel link farm directory</term>
504 <listitem><para>The location of the
505 SysV runlevel link farm directory
506 varies between distributions. systemd
507 will take the link farm into account
508 when figuring out whether a service
509 shall be enabled. Note that a service
510 unit with a native unit configuration
511 file cannot be started by activating it
512 in the SysV runlevel link
513 farm.</para></listitem>
519 <title>Signals</title>
525 <listitem><para>Upon receiving this
526 signal the systemd system manager
527 serializes its state, reexecutes
528 itself and deserializes the saved
529 state again. This is mostly equivalent
530 to <command>systemctl
531 daemon-reexec</command>.</para>
533 <para>systemd session managers will
535 <filename>exit.target</filename> unit
536 when this signal is received. This is
538 <command>systemctl --session start
539 exit.target</command>.</para></listitem>
545 <listitem><para>Upon receiving this
546 signal the systemd system manager will
548 <filename>ctrl-alt-del.target</filename> unit. This
549 is mostly equivalent to
550 <command>systemctl start
551 ctl-alt-del.target</command>.</para>
553 <para>systemd session managers
554 treat this signal the same way as
555 SIGTERM.</para></listitem>
559 <term>SIGWINCH</term>
561 <listitem><para>When this signal is
562 received the systemd system manager
564 <filename>kbrequest.target</filename>
565 unit. This is mostly equivalent to
566 <command>systemctl start
567 kbrequest.target</command>.</para>
569 <para>This signal is ignored by
571 managers.</para></listitem>
577 <listitem><para>When this signal is
578 received the systemd manager
580 <filename>sigpwr.target</filename>
581 unit. This is mostly equivalent to
582 <command>systemctl start
583 sigpwr.target</command>.</para></listitem>
589 <listitem><para>When this signal is
590 received the systemd manager will try
591 to reconnect to the D-Bus
592 bus.</para></listitem>
598 <listitem><para>When this signal is
599 received the systemd manager will log
600 its complete state in human readable
601 form. The data logged is the same as
602 printed by <command>systemctl
603 dump</command>.</para></listitem>
609 <listitem><para>Reloads the complete
610 daemon configuration. This is mostly
611 equivalent to <command>systemctl
612 daemon-reload</command>.</para></listitem>
616 <term>SIGRTMIN+0</term>
618 <listitem><para>Enters default mode, starts the
619 <filename>default.target</filename>
620 unit. This is mostly equivalent to
621 <command>systemctl start
622 default.target</command>.</para></listitem>
626 <term>SIGRTMIN+1</term>
628 <listitem><para>Enters rescue mode,
630 <filename>rescue.target</filename>
631 unit. This is mostly equivalent to
632 <command>systemctl isolate
633 rescue.target</command>.</para></listitem>
637 <term>SIGRTMIN+2</term>
639 <listitem><para>Enters emergency mode,
641 <filename>emergency.service</filename>
642 unit. This is mostly equivalent to
643 <command>systemctl isolate
644 emergency.service</command>.</para></listitem>
648 <term>SIGRTMIN+3</term>
650 <listitem><para>Halts the machine,
652 <filename>halt.target</filename>
653 unit. This is mostly equivalent to
654 <command>systemctl start
655 halt.target</command>.</para></listitem>
659 <term>SIGRTMIN+4</term>
661 <listitem><para>Powers off the machine,
663 <filename>poweroff.target</filename>
664 unit. This is mostly equivalent to
665 <command>systemctl start
666 poweroff.target</command>.</para></listitem>
670 <term>SIGRTMIN+5</term>
672 <listitem><para>Reboots the machine,
674 <filename>reboot.target</filename>
675 unit. This is mostly equivalent to
676 <command>systemctl start
677 reboot.target</command>.</para></listitem>
683 <title>Environment</title>
687 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
688 <listitem><para>systemd reads the
689 log level from this environment
690 variable. This can be overridden with
691 <option>--log-level=</option>.</para></listitem>
695 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
696 <listitem><para>systemd reads the
697 log target from this environment
698 variable. This can be overridden with
699 <option>--log-target=</option>.</para></listitem>
703 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
704 <listitem><para>Controls whether
705 systemd highlights important log
706 messages. This can be overridden with
707 <option>--log-color=</option>.</para></listitem>
711 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
712 <listitem><para>Controls whether
713 systemd prints the code location along
714 with log messages. This can be
716 <option>--log-location=</option>.</para></listitem>
720 <term><varname>$XDG_CONFIG_HOME</varname></term>
721 <term><varname>$XDG_CONFIG_DIRS</varname></term>
722 <term><varname>$XDG_DATA_HOME</varname></term>
723 <term><varname>$XDG_DATA_DIRS</varname></term>
725 <listitem><para>The systemd session
726 manager uses these variables in
727 accordance to the <ulink
728 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
729 Base Directory specification</ulink>
730 to find its configuration.</para></listitem>
734 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
736 <listitem><para>Controls where systemd
738 files.</para></listitem>
742 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
744 <listitem><para>Controls where systemd
745 looks for SysV init scripts.</para></listitem>
749 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
751 <listitem><para>Controls where systemd
752 looks for SysV init script runlevel link
753 farms.</para></listitem>
757 <term><varname>$LISTEN_PID</varname></term>
758 <term><varname>$LISTEN_FDS</varname></term>
760 <listitem><para>Set by systemd for
761 supervised processes during
762 socket-based activation. See
763 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
764 for more information.
769 <term><varname>$NOTIFY_SOCKET</varname></term>
771 <listitem><para>Set by systemd for
772 supervised processes for status and
773 start-up completion notification. See
774 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
775 for more information.
782 <title>Kernel Command Line</title>
784 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
788 <term><varname>systemd.unit=</varname></term>
790 <listitem><para>Overrides the unit to
791 activate on boot. Defaults to
792 <filename>default.target</filename>. This
793 may be used to temporarily boot into a
794 different boot unit, for example
795 <filename>rescue.target</filename> or
796 <filename>emergency.service</filename>. See
797 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
798 for details about these
799 units.</para></listitem>
803 <term><varname>systemd.log_target=</varname></term>
804 <term><varname>systemd.log_level=</varname></term>
805 <term><varname>systemd.log_color=</varname></term>
806 <term><varname>systemd.log_location=</varname></term>
808 <listitem><para>Controls log output,
809 with the same effect as the
810 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
811 environment variables described above.</para></listitem>
815 <term><varname>systemd.dump_core=</varname></term>
817 <listitem><para>Takes a boolean
818 argument. If <option>true</option>
819 systemd dumps core when it
820 crashes. Otherwise no core dump is
822 <option>true</option>.</para></listitem>
826 <term><varname>systemd.crash_shell=</varname></term>
828 <listitem><para>Takes a boolean
829 argument. If <option>true</option>
830 systemd spawns a shell when it
831 crashes. Otherwise no core dump is
833 <option>false</option>, for security
834 reasons, as the shell is not protected
836 authentication.</para></listitem>
840 <term><varname>systemd.crash_chvt=</varname></term>
842 <listitem><para>Takes an integer
843 argument. If positive systemd
844 activates the specified virtual
845 terminal when it crashes. Defaults to
846 <literal>-1</literal>.</para></listitem>
850 <term><varname>systemd.show_status=</varname></term>
852 <listitem><para>Takes a boolean
853 argument. If <option>true</option>
854 shows terse service status updates on
855 the console during bootup. Defaults to
856 <option>true</option>.</para></listitem>
863 <title>Sockets and FIFOs</title>
867 <term><filename>@/org/freedesktop/systemd1/notify</filename></term>
869 <listitem><para>Daemon status
870 notification socket. This is an AF_UNIX
871 datagram socket in the Linux abstract
872 namespace, and is used to implement
873 the daemon notification logic as
875 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
880 <term><filename>@/org/freedesktop/systemd1/logger</filename></term>
882 <listitem><para>Used internally by the
883 <filename>systemd-logger.service</filename>
884 unit to connect STDOUT and/or STDERR
885 of spawned processes to
886 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
887 or the kernel log buffer. This is an
888 AF_UNIX stream socket in the Linux
889 abstract namespace.</para></listitem>
893 <term><filename>@/org/freedesktop/systemd1/private</filename></term>
895 <listitem><para>Used internally as
896 communication channel between
897 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
898 and the systemd process. This is an
899 AF_UNIX stream socket in the Linux
900 abstract namespace. This interface is
901 private to systemd and should not be
903 projects.</para></listitem>
907 <term><filename>/dev/initctl</filename></term>
909 <listitem><para>Limited compatibility
910 support for the SysV client interface,
911 as implemented by the
912 <filename>systemd-initctl.service</filename>
913 unit. This is a named pipe in the file
914 system. This interface is obsolete and
915 should not be used in new
916 applications.</para></listitem>
922 <title>See Also</title>
924 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
925 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
926 <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
927 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
928 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
929 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
930 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
931 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
932 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>