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 maintenance. 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
452 directories only with the
453 <command>enable</command> and
454 <command>disable</command> commands of
456 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
457 tool.</para></listitem>
463 <term>Session unit directories</term>
465 <listitem><para>Similar rules apply
467 directories. However, here the <ulink
468 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
469 Base Directory specification</ulink>
471 units. Applications should place their
472 unit files in the directory returned
473 by <command>pkg-config systemd
474 --variable=systemdsessionunitdir</command>. Global
475 configuration is done in the directory
476 reported by <command>pkg-config
478 --variable=systemdsessionconfdir</command>. The
479 <command>enable</command> and
480 <command>disable</command> commands of
482 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
483 tool can handle both global (i.e. for
484 all users) and private (for one user)
485 enabling/disabling of
486 units.</para></listitem>
492 <term>SysV init scripts directory</term>
494 <listitem><para>The location of the
495 SysV init script directory varies
496 between distributions. If systemd
497 cannot find a native unit file for a
498 requested service, it will look for a
499 SysV init script of the same name
501 <filename>.service</filename> suffix
502 removed).</para></listitem>
508 <term>SysV runlevel link farm directory</term>
510 <listitem><para>The location of the
511 SysV runlevel link farm directory
512 varies between distributions. systemd
513 will take the link farm into account
514 when figuring out whether a service
515 shall be enabled. Note that a service
516 unit with a native unit configuration
517 file cannot be started by activating it
518 in the SysV runlevel link
519 farm.</para></listitem>
525 <title>Signals</title>
531 <listitem><para>Upon receiving this
532 signal the systemd system manager
533 serializes its state, reexecutes
534 itself and deserializes the saved
535 state again. This is mostly equivalent
536 to <command>systemctl
537 daemon-reexec</command>.</para>
539 <para>systemd session managers will
541 <filename>exit.target</filename> unit
542 when this signal is received. This is
544 <command>systemctl --session start
545 exit.target</command>.</para></listitem>
551 <listitem><para>Upon receiving this
552 signal the systemd system manager will
554 <filename>ctrl-alt-del.target</filename> unit. This
555 is mostly equivalent to
556 <command>systemctl start
557 ctl-alt-del.target</command>.</para>
559 <para>systemd session managers
560 treat this signal the same way as
561 SIGTERM.</para></listitem>
565 <term>SIGWINCH</term>
567 <listitem><para>When this signal is
568 received the systemd system manager
570 <filename>kbrequest.target</filename>
571 unit. This is mostly equivalent to
572 <command>systemctl start
573 kbrequest.target</command>.</para>
575 <para>This signal is ignored by
577 managers.</para></listitem>
583 <listitem><para>When this signal is
584 received the systemd manager
586 <filename>sigpwr.target</filename>
587 unit. This is mostly equivalent to
588 <command>systemctl start
589 sigpwr.target</command>.</para></listitem>
595 <listitem><para>When this signal is
596 received the systemd manager will try
597 to reconnect to the D-Bus
598 bus.</para></listitem>
604 <listitem><para>When this signal is
605 received the systemd manager will log
606 its complete state in human readable
607 form. The data logged is the same as
608 printed by <command>systemctl
609 dump</command>.</para></listitem>
615 <listitem><para>Reloads the complete
616 daemon configuration. This is mostly
617 equivalent to <command>systemctl
618 daemon-reload</command>.</para></listitem>
622 <term>SIGRTMIN+0</term>
624 <listitem><para>Enters default mode, starts the
625 <filename>default.target</filename>
626 unit. This is mostly equivalent to
627 <command>systemctl start
628 default.target</command>.</para></listitem>
632 <term>SIGRTMIN+1</term>
634 <listitem><para>Enters rescue mode,
636 <filename>rescue.target</filename>
637 unit. This is mostly equivalent to
638 <command>systemctl isolate
639 rescue.target</command>.</para></listitem>
643 <term>SIGRTMIN+2</term>
645 <listitem><para>Enters emergency mode,
647 <filename>emergency.service</filename>
648 unit. This is mostly equivalent to
649 <command>systemctl isolate
650 emergency.service</command>.</para></listitem>
654 <term>SIGRTMIN+3</term>
656 <listitem><para>Halts the machine,
658 <filename>halt.target</filename>
659 unit. This is mostly equivalent to
660 <command>systemctl start
661 halt.target</command>.</para></listitem>
665 <term>SIGRTMIN+4</term>
667 <listitem><para>Powers off the machine,
669 <filename>poweroff.target</filename>
670 unit. This is mostly equivalent to
671 <command>systemctl start
672 poweroff.target</command>.</para></listitem>
676 <term>SIGRTMIN+5</term>
678 <listitem><para>Reboots the machine,
680 <filename>reboot.target</filename>
681 unit. This is mostly equivalent to
682 <command>systemctl start
683 reboot.target</command>.</para></listitem>
689 <title>Environment</title>
693 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
694 <listitem><para>systemd reads the
695 log level from this environment
696 variable. This can be overridden with
697 <option>--log-level=</option>.</para></listitem>
701 <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
702 <listitem><para>systemd reads the
703 log target from this environment
704 variable. This can be overridden with
705 <option>--log-target=</option>.</para></listitem>
709 <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
710 <listitem><para>Controls whether
711 systemd highlights important log
712 messages. This can be overridden with
713 <option>--log-color=</option>.</para></listitem>
717 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
718 <listitem><para>Controls whether
719 systemd prints the code location along
720 with log messages. This can be
722 <option>--log-location=</option>.</para></listitem>
726 <term><varname>$XDG_CONFIG_HOME</varname></term>
727 <term><varname>$XDG_CONFIG_DIRS</varname></term>
728 <term><varname>$XDG_DATA_HOME</varname></term>
729 <term><varname>$XDG_DATA_DIRS</varname></term>
731 <listitem><para>The systemd session
732 manager uses these variables in
733 accordance to the <ulink
734 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
735 Base Directory specification</ulink>
736 to find its configuration.</para></listitem>
740 <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
742 <listitem><para>Controls where systemd
744 files.</para></listitem>
748 <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
750 <listitem><para>Controls where systemd
751 looks for SysV init scripts.</para></listitem>
755 <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
757 <listitem><para>Controls where systemd
758 looks for SysV init script runlevel link
759 farms.</para></listitem>
763 <term><varname>$LISTEN_PID</varname></term>
764 <term><varname>$LISTEN_FDS</varname></term>
766 <listitem><para>Set by systemd for
767 supervised processes during
768 socket-based activation. See
769 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
770 for more information.
775 <term><varname>$NOTIFY_SOCKET</varname></term>
777 <listitem><para>Set by systemd for
778 supervised processes for status and
779 start-up completion notification. See
780 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
781 for more information.
788 <title>Kernel Command Line</title>
790 <para>When run as system instance systemd parses a few kernel command line arguments:</para>
794 <term><varname>systemd.unit=</varname></term>
796 <listitem><para>Overrides the unit to
797 activate on boot. Defaults to
798 <filename>default.target</filename>. This
799 may be used to temporarily boot into a
800 different boot unit, for example
801 <filename>rescue.target</filename> or
802 <filename>emergency.service</filename>. See
803 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
804 for details about these
805 units.</para></listitem>
809 <term><varname>systemd.log_target=</varname></term>
810 <term><varname>systemd.log_level=</varname></term>
811 <term><varname>systemd.log_color=</varname></term>
812 <term><varname>systemd.log_location=</varname></term>
814 <listitem><para>Controls log output,
815 with the same effect as the
816 <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
817 environment variables described above.</para></listitem>
821 <term><varname>systemd.dump_core=</varname></term>
823 <listitem><para>Takes a boolean
824 argument. If <option>true</option>
825 systemd dumps core when it
826 crashes. Otherwise no core dump is
828 <option>true</option>.</para></listitem>
832 <term><varname>systemd.crash_shell=</varname></term>
834 <listitem><para>Takes a boolean
835 argument. If <option>true</option>
836 systemd spawns a shell when it
837 crashes. Otherwise no core dump is
839 <option>false</option>, for security
840 reasons, as the shell is not protected
842 authentication.</para></listitem>
846 <term><varname>systemd.crash_chvt=</varname></term>
848 <listitem><para>Takes an integer
849 argument. If positive systemd
850 activates the specified virtual
851 terminal when it crashes. Defaults to
852 <literal>-1</literal>.</para></listitem>
856 <term><varname>systemd.show_status=</varname></term>
858 <listitem><para>Takes a boolean
859 argument. If <option>true</option>
860 shows terse service status updates on
861 the console during bootup. Defaults to
862 <option>true</option>.</para></listitem>
869 <title>Sockets and FIFOs</title>
873 <term><filename>@/org/freedesktop/systemd1/notify</filename></term>
875 <listitem><para>Daemon status
876 notification socket. This is an AF_UNIX
877 datagram socket in the Linux abstract
878 namespace, and is used to implement
879 the daemon notification logic as
881 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
886 <term><filename>@/org/freedesktop/systemd1/logger</filename></term>
888 <listitem><para>Used internally by the
889 <filename>systemd-logger.service</filename>
890 unit to connect STDOUT and/or STDERR
891 of spawned processes to
892 <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
893 or the kernel log buffer. This is an
894 AF_UNIX stream socket in the Linux
895 abstract namespace.</para></listitem>
899 <term><filename>@/org/freedesktop/systemd1/private</filename></term>
901 <listitem><para>Used internally as
902 communication channel between
903 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
904 and the systemd process. This is an
905 AF_UNIX stream socket in the Linux
906 abstract namespace. This interface is
907 private to systemd and should not be
909 projects.</para></listitem>
913 <term><filename>/dev/initctl</filename></term>
915 <listitem><para>Limited compatibility
916 support for the SysV client interface,
917 as implemented by the
918 <filename>systemd-initctl.service</filename>
919 unit. This is a named pipe in the file
920 system. This interface is obsolete and
921 should not be used in new
922 applications.</para></listitem>
928 <title>See Also</title>
930 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
931 <citerefentry><refentrytitle>systemadm</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
932 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
933 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
934 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
935 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
936 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
937 <citerefentry><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>