chiark / gitweb /
keymap: Explicitly match "any product name" for "all models from vendor" rules
[elogind.git] / man / systemd.xml
index ef95641387568f227febef3e97ba3ec1347ac144..9f58bc2f8279a1e6e771192736d6dc5de5ac8913 100644 (file)
                 <title>Concepts</title>
 
                 <para>systemd provides a dependency system between
                 <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
                 <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
                 reference. Note that the various unit types may have a
                 number of additional substates, which are mapped to
                 the five generalized unit states described
                 <para>The following unit types are available:</para>
 
                 <orderedlist>
                 <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>
                         daemons and the processes they consist of. For
                         details see
                         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
                         objects change or are modified. See
                         <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 
                         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
                 </orderedlist>
 
                 <para>Units are named as their configuration
                 individual Linux control groups named after the unit
                 which they belong to in the private systemd
                 hierarchy. (see <ulink
                 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
                 for more information about control groups, or short
                 "cgroups"). systemd uses this to effectively keep
                 track of processes. Control group information is
 
                 <para>Systemd contains native implementations of
                 various tasks that need to be executed as part of the
 
                 <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
                 configures the loopback network device. It also sets
                 up and mounts various API file systems, such as
                 <filename>/sys</filename> or
 
                                 <para>systemd user managers
                                 treat this signal the same way as
 
                                 <para>systemd user managers
                                 treat this signal the same way as
-                                SIGTERM.</para></listitem>
+                                <constant>SIGTERM</constant>.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
                         </varlistentry>
 
                         <varlistentry>
                                 <term><varname>systemd.setenv=</varname></term>
 
                                 <listitem><para>Takes a string
                                 <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>
                         </varlistentry>
 
                         <varlistentry>