X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fsystemd.xml;h=9f58bc2f8279a1e6e771192736d6dc5de5ac8913;hb=756c9a2499ca377b9e96ea6fc6911ff64040174e;hp=ef95641387568f227febef3e97ba3ec1347ac144;hpb=74d005783e355acc784d123024e33bbb66ef9ef1;p=elogind.git

diff --git a/man/systemd.xml b/man/systemd.xml
index ef9564138..9f58bc2f8 100644
--- a/man/systemd.xml
+++ b/man/systemd.xml
@@ -285,25 +285,27 @@
                 <title>Concepts</title>
 
                 <para>systemd provides a dependency system between
-                various entities called "units". Units encapsulate
-                various objects that are relevant for system boot-up
-                and maintenance. The majority of units are configured
-                in unit configuration files, whose syntax and basic
-                set of options is described in
+                various entities called "units" of 12 different
+                types. Units encapsulate various objects that are
+                relevant for system boot-up and maintenance. The
+                majority of units are configured in unit configuration
+                files, whose syntax and basic set of options is
+                described in
                 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                 however some are created automatically from other
-                configuration or dynamically from system state. Units
-                may be 'active' (meaning started, bound, plugged in,
-                ...  depending on the unit type, see below), or
-                'inactive' (meaning stopped, unbound, unplugged, ...),
-                as well as in the process of being activated or
-                deactivated, i.e. between the two states (these states
-                are called 'activating', 'deactivating'). A special
-                'failed' state is available as well which is very
-                similar to 'inactive' and is entered when the service
-                failed in some way (process returned error code on
-                exit, or crashed, or an operation timed out). If this
-                state is entered the cause will be logged, for later
+                configuration, dynamically from system state or
+                programmatically at runtime. Units may be "active"
+                (meaning started, bound, plugged in, ..., depending on
+                the unit type, see below), or "inactive" (meaning
+                stopped, unbound, unplugged, ...), as well as in the
+                process of being activated or deactivated,
+                i.e. between the two states (these states are called
+                "activating", "deactivating"). A special "failed"
+                state is available as well, which is very similar to
+                "inactive" and is entered when the service failed in
+                some way (process returned error code on exit, or
+                crashed, or an operation timed out). If this state is
+                entered, the cause will be logged, for later
                 reference. Note that the various unit types may have a
                 number of additional substates, which are mapped to
                 the five generalized unit states described
@@ -312,7 +314,7 @@
                 <para>The following unit types are available:</para>
 
                 <orderedlist>
-                        <listitem><para>Service units, which control
+                        <listitem><para>Service units, which start and control
                         daemons and the processes they consist of. For
                         details see
                         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
@@ -369,6 +371,18 @@
                         objects change or are modified. See
                         <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 
+                        <listitem><para>Slice units may be used to
+                        group units which manage system processes
+                        (such as service and scope units) in a
+                        hierarchical tree for resource management
+                        purposes. See
+                        <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Scope units are similar to
+                        service units, but manage foreign processes
+                        instead of starting them as well. See
+                        <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
                 </orderedlist>
 
                 <para>Units are named as their configuration
@@ -425,7 +439,7 @@
                 individual Linux control groups named after the unit
                 which they belong to in the private systemd
                 hierarchy. (see <ulink
-                url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
+                url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
                 for more information about control groups, or short
                 "cgroups"). systemd uses this to effectively keep
                 track of processes. Control group information is
@@ -473,7 +487,7 @@
 
                 <para>Systemd contains native implementations of
                 various tasks that need to be executed as part of the
-                boot process. For example, it sets the host name or
+                boot process. For example, it sets the hostname or
                 configures the loopback network device. It also sets
                 up and mounts various API file systems, such as
                 <filename>/sys</filename> or
@@ -643,7 +657,7 @@
 
                                 <para>systemd user managers
                                 treat this signal the same way as
-                                SIGTERM.</para></listitem>
+                                <constant>SIGTERM</constant>.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
@@ -1099,16 +1113,11 @@
                                 <term><varname>systemd.setenv=</varname></term>
 
                                 <listitem><para>Takes a string
-                                argument in the form
-                                VARIABLE=VALUE. May be used to set
-                                environment variables for the init
-                                process and all its children at boot
-                                time. May be used more than once to
-                                set multiple variables. If the equal
-                                sign and variable are missing it unsets
-                                an environment variable which might be
-                                passed in from the initial ram
-                                disk.</para></listitem>
+                                argument in the form VARIABLE=VALUE.
+                                May be used to set default environment
+                                variables to add to forked child processes.
+                                May be used more than once to set multiple
+                                variables.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>