man/systemd.unit.xml

@@ -560,44 +560,22 @@
         effect.</para></listitem>
       </varlistentry>
 
-      <varlistentry>
-        <term><varname>Wants=</varname></term>
-
-        <listitem><para>Configures requirement dependencies on other units. This option may be specified more
-        than once or multiple space-separated units may be specified in one option in which case dependencies
-        for all listed names will be created. Dependencies of this type may also be configured outside of the
-        unit configuration file by adding a symlink to a <filename>.wants/</filename> directory accompanying
-        the unit file. For details, see above.</para>
-
-        <para>Units listed in this option will be started if the configuring unit is. However, if the listed
-        units fail to start or cannot be added to the transaction, this has no impact on the validity of the
-        transaction as a whole, and this unit will still be started. This is the recommended way to hook
-        start-up of one unit to the start-up of another unit.</para>
-
-        <para>Note that requirement dependencies do not influence the order in which services are started or
-        stopped. This has to be configured independently with the <varname>After=</varname> or
-        <varname>Before=</varname> options. If unit <filename>foo.service</filename> pulls in unit
-        <filename>bar.service</filename> as configured with <varname>Wants=</varname> and no ordering is
-        configured with <varname>After=</varname> or <varname>Before=</varname>, then both units will be
-        started simultaneously and without any delay between them if <filename>foo.service</filename> is
-        activated.</para></listitem>
-      </varlistentry>
-
       <varlistentry>
         <term><varname>Requires=</varname></term>
 
-        <listitem><para>Similar to <varname>Wants=</varname>, but declares a stronger
+        <listitem><para>Configures requirement dependencies on other units. If this unit gets activated, the units
-        dependency. Dependencies of this type may also be configured by adding a symlink to a
+        listed here will be activated as well. If one of the other units fails to activate, and an ordering dependency
-        <filename>.requires/</filename> directory accompanying the unit file.</para>
+        <varname>After=</varname> on the failing unit is set, this unit will not be started. Besides, with or without
-
+        specifying <varname>After=</varname>, this unit will be stopped if one of the other units is explicitly
-        <para>If this unit gets activated, the units listed will be activated as well. If one of
+        stopped. This option may be specified more than once or multiple space-separated units may be
-        the other units fails to activate, and an ordering dependency <varname>After=</varname> on the
+        specified in one option in which case requirement dependencies for all listed names will be created. Note that
-        failing unit is set, this unit will not be started. Besides, with or without specifying
+        requirement dependencies do not influence the order in which services are started or stopped.  This has to be
-        <varname>After=</varname>, this unit will be stopped if one of the other units is explicitly
+        configured independently with the <varname>After=</varname> or <varname>Before=</varname> options. If a unit
-        stopped.</para>
+        <filename>foo.service</filename> requires a unit <filename>bar.service</filename> as configured with
-
+        <varname>Requires=</varname> and no ordering is configured with <varname>After=</varname> or
-        <para>Often, it is a better choice to use <varname>Wants=</varname> instead of
+        <varname>Before=</varname>, then both units will be started simultaneously and without any delay between them
-        <varname>Requires=</varname> in order to achieve a system that is more robust when dealing with
+        if <filename>foo.service</filename> is activated. Often, it is a better choice to use <varname>Wants=</varname>
+        instead of <varname>Requires=</varname> in order to achieve a system that is more robust when dealing with
         failing services.</para>
 
         <para>Note that this dependency type does not imply that the other unit always has to be in active state when
@@ -607,7 +585,11 @@
         example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not
         propagated to units having a <varname>Requires=</varname> dependency. Use the <varname>BindsTo=</varname>
         dependency type together with <varname>After=</varname> to ensure that a unit may never be in active state
-        without a specific other unit also in active state (see below).</para></listitem>
+        without a specific other unit also in active state (see below).</para>
+
+        <para>Note that dependencies of this type may also be configured outside of the unit configuration file by
+        adding a symlink to a <filename>.requires/</filename> directory accompanying the unit file. For details, see
+        above.</para></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -628,6 +610,24 @@
         </listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><varname>Wants=</varname></term>
+
+        <listitem><para>A weaker version of
+        <varname>Requires=</varname>. Units listed in this option will
+        be started if the configuring unit is. However, if the listed
+        units fail to start or cannot be added to the transaction,
+        this has no impact on the validity of the transaction as a
+        whole. This is the recommended way to hook start-up of one
+        unit to the start-up of another unit.</para>
+
+        <para>Note that dependencies of this type may also be
+        configured outside of the unit configuration file by adding
+        symlinks to a <filename>.wants/</filename> directory
+        accompanying the unit file. For details, see
+        above.</para></listitem>
+      </varlistentry>
+
       <varlistentry>
         <term><varname>BindsTo=</varname></term>
 
@@ -676,18 +676,15 @@
       <varlistentry>
         <term><varname>Conflicts=</varname></term>
 
-        <listitem><para>A space-separated list of unit names. Configures negative requirement
+        <listitem><para>A space-separated list of unit names.
-        dependencies. If a unit has a <varname>Conflicts=</varname> setting on another unit, starting the
+        Configures negative requirement dependencies. If a unit has a
-        former will stop the latter and vice versa.</para>
+        <varname>Conflicts=</varname> setting on another unit,
+        starting the former will stop the latter and vice versa. Note
+        that this setting is independent of and orthogonal to the
+        <varname>After=</varname> and <varname>Before=</varname>
+        ordering dependencies.</para>
 
-        <para>Note that this setting does not imply an ordering dependency, similarly to the
+        <para>If a unit A that conflicts with a unit B is scheduled to
-        <varname>Wants=</varname> and <varname>Requires=</varname> dependencies described above. This means
-        that to ensure that the conflicting unit is stopped before the other unit is started, an
-        <varname>After=</varname> or <varname>Before=</varname> dependency must be declared. It doesn't
-        matter which of the two ordering dependencies is used, because stop jobs are always ordered before
-        start jobs, see the discussion in <varname>Before=</varname>/<varname>After=</varname> below.</para>
-
-        <para>If unit A that conflicts with unit B is scheduled to
         be started at the same time as B, the transaction will either
         fail (in case both are required parts of the transaction) or be
         modified to be fixed (in case one or both jobs are not a
@@ -701,36 +698,29 @@
         <term><varname>Before=</varname></term>
         <term><varname>After=</varname></term>
 
-        <listitem><para>These two settings expect a space-separated list of unit names. They may be specified
+        <listitem><para>These two settings expect a space-separated list of unit names. They configure ordering
-        more than once, in which case dependencies for all listed names are created.</para>
+        dependencies between units. If a unit <filename>foo.service</filename> contains a setting
-
+        <option>Before=bar.service</option> and both units are being started, <filename>bar.service</filename>'s
-        <para>Those two setttings configure ordering dependencies between units. If unit
+        start-up is delayed until <filename>foo.service</filename> has finished starting up.  Note that this setting is
-        <filename>foo.service</filename> contains the setting <option>Before=bar.service</option> and both
+        independent of and orthogonal to the requirement dependencies as configured by <varname>Requires=</varname>,
-        units are being started, <filename>bar.service</filename>'s start-up is delayed until
+        <varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both
-        <filename>foo.service</filename> has finished starting up. <varname>After=</varname> is the inverse
+        the <varname>After=</varname> and <varname>Requires=</varname> options, in which case the unit listed will be
-        of <varname>Before=</varname>, i.e. while <varname>Before=</varname> ensures that the configured unit
+        started before the unit that is configured with these options. This option may be specified more than once, in
-        is started before the listed unit begins starting up, <varname>After=</varname> ensures the opposite,
+        which case ordering dependencies for all listed names are created. <varname>After=</varname> is the inverse of
-        that the listed unit is fully started up before the configured unit is started.</para>
+        <varname>Before=</varname>, i.e. while <varname>After=</varname> ensures that the configured unit is started
-
+        after the listed unit finished starting up, <varname>Before=</varname> ensures the opposite, that the
-        <para>When two units with an ordering dependency between them are shut down, the inverse of the
+        configured unit is fully started up before the listed unit is started. Note that when two units with an
-        start-up order is applied. i.e. if a unit is configured with <varname>After=</varname> on another
+        ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is
-        unit, the former is stopped before the latter if both are shut down. Given two units with any
+        configured with <varname>After=</varname> on another unit, the former is stopped before the latter if both are
-        ordering dependency between them, if one unit is shut down and the other is started up, the shutdown
+        shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is
-        is ordered before the start-up. It doesn't matter if the ordering dependency is
+        started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is
-        <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which
+        <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which of the two
-        of the two is shut down, as long as one is shut down and the other is started up; the shutdown is
+        is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the
-        ordered before the start-up in all cases. If two units have no ordering dependencies between them,
+        start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started
-        they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit
+        up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished
-        type when precisely a unit has finished starting up. Most importantly, for service units start-up is
+        starting up. Most importantly, for service units start-up is considered completed for the purpose of
-        considered completed for the purpose of <varname>Before=</varname>/<varname>After=</varname> when all
+        <varname>Before=</varname>/<varname>After=</varname> when all its configured start-up commands have been
-        its configured start-up commands have been invoked and they either failed or reported start-up
+        invoked and they either failed or reported start-up success.</para></listitem>
-        success.</para>
-
-        <para>Note that those settings are independent of and orthogonal to the requirement dependencies as
-        configured by <varname>Requires=</varname>, <varname>Wants=</varname>, <varname>Requisite=</varname>,
-        or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both the
-        <varname>After=</varname> and <varname>Wants=</varname> options, in which case the unit listed will
-        be started before the unit that is configured with these options.</para></listitem>
       </varlistentry>
 
       <varlistentry>

src/udev/udev-builtin-blkid.c

@@ -264,7 +264,7 @@ static int builtin_blkid(sd_device *dev, int argc, char *argv[], bool test) {
         if (r < 0)
                 return log_device_debug_errno(dev, r, "Failed to get device name: %m");
 
-        fd = open(devnode, O_RDONLY|O_CLOEXEC|O_NONBLOCK);
+        fd = open(devnode, O_RDONLY|O_CLOEXEC);
         if (fd < 0)
                 return log_device_debug_errno(dev, errno, "Failed to open block device %s: %m", devnode);