units: rely only on isolate to remove running services when entering rescue/emergency...

[elogind.git] / man / daemon.xml

diff --git a/man/daemon.xml b/man/daemon.xml
index 8e9e9395321c657a6f6c85ca802f1d4473843b9d..fb22e6c6165d88f4d950542fba0e7a37baf0d25a 100644 (file)
--- a/man/daemon.xml
+++ b/man/daemon.xml
@@ -384,7 +384,7 @@
                 communication channels are established already, and no
                 request is lost because client requests will be queued
                 by the bus system (in case of D-Bus) or the kernel (in
-                case of sockets), until the activation
+                case of sockets), until the activation is
                 completed.</para>
 
                 <refsect2>
@@ -678,7 +678,8 @@
                                 <listitem><para>If your daemon
                                 registers a D-Bus name on the bus,
                                 make sure to use
-                                <varname>Type=dbus</varname> if
+                                <varname>Type=dbus</varname> in the
+                                service file if
                                 possible.</para></listitem>
 
                                 <listitem><para>Make sure to set a
@@ -703,16 +704,45 @@
                                 operating
                                 system-independent.</para></listitem>
 
+                                <listitem><para>Since not all syslog
+                                implementations are socket-activatable
+                                yet, it is recommended to place an
+                                <varname>After=syslog.target</varname>
+                                dependency in service files for
+                                daemons that can log to
+                                syslog. <filename>syslog.target</filename>
+                                then either pulls in the syslog daemon
+                                itself or simply the activation
+                                socket. A <varname>Wants=</varname> or
+                                even <varname>Requires=</varname>
+                                dependency should generally not be
+                                added, since it should be up to the
+                                administrator whether he wants to
+                                enable logging or not, and most syslog
+                                clients work fine if no log daemon is
+                                running.</para></listitem>
+
                                 <listitem><para>Make sure to include
-                                an <literal>[Install]</literal> section including
-                                installation information for the unit
-                                file. See
+                                an <literal>[Install]</literal>
+                                section including installation
+                                information for the unit file. See
                                 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
                                 for details. To activate your service
                                 on boot make sure to add a
                                 <varname>WantedBy=multi-user.target</varname>
                                 or
-                                <varname>WantedBy=graphical.target</varname> directive.</para></listitem>
+                                <varname>WantedBy=graphical.target</varname>
+                                directive. To activate your socket on
+                                boot, make sure to add
+                                <varname>WantedBy=sockets.target</varname>. Usually
+                                you also want to make sure that when
+                                your service is installed your socket
+                                is installed too, hence add
+                                <varname>Also=foo.socket</varname> in
+                                your service file
+                                <filename>foo.service</filename>, for
+                                a hypothetical program
+                                <filename>foo</filename>.</para></listitem>
 
                         </orderedlist>
                 </refsect2>
@@ -726,7 +756,7 @@
                         install their systemd unit files in the
                         directory returned by <command>pkg-config
                         systemd
-                        --variable=systemdsystemnunitdir</command>
+                        --variable=systemdsystemunitdir</command>
                         (for system services),
                         resp. <command>pkg-config systemd
                         --variable=systemdsessionunitdir</command>
@@ -793,13 +823,22 @@ endif</programlisting>
                         package managers:</para>
 
                         <programlisting>%post
-/usr/bin/systemd-install --start enable foobar.service foobar.socket >/dev/null 2>&amp;1 || :
+/usr/bin/systemd-install --realize enable foobar.service foobar.socket >/dev/null 2>&amp;1 || :
 
 %preun
 if [ "$1" -eq 0 ]; then
-        /usr/bin/systemd-install --start disable foobar.service foobar.socket >/dev/null 2>&amp;1 || :
+        /usr/bin/systemd-install --realize disable foobar.service foobar.socket >/dev/null 2>&amp;1 || :
 fi</programlisting>
 
+                        <para>Depending on whether your service should
+                        or should not be started/stopped/restarted
+                        during package installation, deinstallation or
+                        upgrade, a different argument to
+                        <option>--realize=</option> may be
+                        specified. See
+                        <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+                        for details.</para>
+
                 </refsect2>
         </refsect1>
 
@@ -809,8 +848,8 @@ fi</programlisting>
                 <para>Since new-style init systems such as systemd are
                 compatible with traditional SysV init systems it is
                 not strictly necessary to port existing daemons to the
-                new style. However doing this offers additional
-                functionality to the daemons as well as it simplifies
+                new style. However doing so offers additional
+                functionality to the daemons as well as simplifying
                 integration into new-style init systems.</para>
 
                 <para>To port an existing SysV compatible daemon the
@@ -849,7 +888,7 @@ fi</programlisting>
                         left-over file descriptors are passed to
                         executed processes, it might be a good choice
                         to simply skip the closing of all remaining
-                        open file descriptors if file descriptors are
+                        open file descriptors if sockets are
                         passed.</para></listitem>
 
                         <listitem><para>Write and install a systemd