chiark / gitweb /
main: replace --running-as= by --session and --system do mimic related tools and...
[elogind.git] / man / systemd.xml
index ba775c5..d19094c 100644 (file)
 
                                 <listitem><para>Extract D-Bus
                                 interface introspection data. This is
-                                mostly useful at build at install time
+                                mostly useful at install time
                                 to generate data suitable for the
                                 D-Bus interfaces
                                 repository. Optionally the interface
                                 <filename>default.target</filename>.</para></listitem>
                         </varlistentry>
                         <varlistentry>
-                                <term><option>--running-as=</option></term>
+                                <term><option>--system</option></term>
+                                <term><option>--session</option></term>
 
-                                <listitem><para>Tell systemd to run in
-                                a particular mode. Argument is one of
-                                <option>system</option>,
-                                <option>session</option>. Normally it
-                                should not be necessary to pass this
-                                option, as systemd automatically
-                                detects the mode it is started
-                                in. This call is hence of little use
-                                except for
+                                <listitem><para>Tell systemd to run a
+                                system instance (resp. session
+                                instance), even if the process ID is
+                                not 1 (resp. is 1), i.e. system is not
+                                (resp. is) run as init process.
+                                Normally it should not be necessary to
+                                pass these options, as systemd
+                                automatically detects the mode it is
+                                started in. These options are hence of
+                                little use except for
                                 debugging.</para></listitem>
                         </varlistentry>
                         <varlistentry>
                 configuration or dynamically from system state. Units
                 may be active (meaning started, bound, plugged in, ...
                 depending on the unit type), or inactive (meaning
-                stopped, unbound, unplugged, ...), as well is in the
+                stopped, unbound, unplugged, ...), as well as in the
                 process of being activated or deactivated,
                 i.e. between the two states. The following unit types
                 are available:</para>
                         systemd. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 
                         <listitem><para>Path units may be used
-                        activate other services when file system
+                        to activate other services when file system
                         objects change or are modified. See
                         <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 
                 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 
                 <para>On boot systemd activates the target unit
-                <filename>default.target</filename> whose job it is to
+                <filename>default.target</filename> whose job is to
                 activate on-boot services and other on-boot units by
                 pulling them in via dependencies. Usually the unit
                 name is just an alias (symlink) for either
                 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
                 for details about these target units.</para>
 
-                <para>Processes systemd spawns ared placed in
+                <para>Processes systemd spawns are placed in
                 individual Linux control groups named after the unit
                 which they belong to in the private systemd
                 hierarchy. (see <ulink
                 simply read as an alternative (though limited)
                 configuration file format. The SysV
                 <filename>/dev/initctl</filename> interface is
-                provided, and comaptibility implementations of the
-                various SysV client tools available. In addition to
-                that various established Unix functionality such as
+                provided, and compatibility implementations of the
+                various SysV client tools are available. In addition to
+                that, various established Unix functionality such as
                 <filename>/etc/fstab</filename> or the
                 <filename>utmp</filename> database are
                 supported.</para>
                                 when figuring out whether a service
                                 shall be enabled. Note that a service
                                 unit with a native unit configuration
-                                file can be started by activating it
+                                file cannot be started by activating it
                                 in the SysV runlevel link
                                 farm.</para></listitem>
                         </varlistentry>