chiark / gitweb /
manager: rename 'maintenance' state to 'failed' to avoid user confusion
[elogind.git] / man / systemd.unit.xml
index 250989fe0f0b044f6234fe58b4ec6c817bb85d7c..3bc5d3c66f6f8453712ffdbcc481cb1ca8467463 100644 (file)
 
                                 <listitem><para>Lists one or more
                                 units that are activated when this
 
                                 <listitem><para>Lists one or more
                                 units that are activated when this
-                                unit fails (i.e. enters maintenance
-                                state).</para></listitem>
+                                unit enters the
+                                '<literal>failed</literal>'
+                                state.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
                         </varlistentry>
 
                         <varlistentry>
                                 time. If this time limit is reached
                                 the job will be cancelled, the unit
                                 however will not change state or even
                                 time. If this time limit is reached
                                 the job will be cancelled, the unit
                                 however will not change state or even
-                                enter maintenance mode. This value
-                                defaults to 0 (job timeouts disabled),
-                                except for device units. NB: this
-                                timeout is independent from any
-                                unit-specific timeout (for example,
-                                the timeout set with
+                                enter the '<literal>failed</literal>'
+                                mode. This value defaults to 0 (job
+                                timeouts disabled), except for device
+                                units. NB: this timeout is independent
+                                from any unit-specific timeout (for
+                                example, the timeout set with
                                 <varname>Timeout=</varname> in service
                                 <varname>Timeout=</varname> in service
-                                units) as the job timeout has no effect
-                                on the unit itself, only on the job
-                                that might be pending for it. Or in
-                                other words: unit-specific timeouts
+                                units) as the job timeout has no
+                                effect on the unit itself, only on the
+                                job that might be pending for it. Or
+                                in other words: unit-specific timeouts
                                 are useful to abort unit state
                                 changes, and revert them. The job
                                 timeout set with this option however
                                 are useful to abort unit state
                                 changes, and revert them. The job
                                 timeout set with this option however
-                                is useful to abort only the job waiting
-                                for the unit state to change.</para></listitem>
+                                is useful to abort only the job
+                                waiting for the unit state to
+                                change.</para></listitem>
                         </varlistentry>
 
                 </variablelist>
                         </varlistentry>
 
                 </variablelist>