Compare commits

...

4 Commits

Author SHA1 Message Date
Michal Suchanek 581e2d96fc libblkid: open device in nonblock mode.
When autoclose is set (kernel default but many distributions reverse the
setting) opening a CD-rom device causes the tray to close.

The function of blkid is to report the current state of the device and
not to change it. Hence it should use O_NONBLOCK when opening the
device to avoid closing a CD-rom tray.

blkid is used liberally in scripts so it can potentially interfere with
the user operating the CD-rom hardware.

[kzak@redhat.com: add O_NONBLOCK also to:
                  - wipefs
                  - blkid_new_probe_from_filename()
                  - blkid_evaluate_tag()]

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Karel Zak <kzak@redhat.com>
(cherry picked from commit 39f5af25982d8b0244000e92a9d0e0e6557d0e17)
2019-11-08 12:11:32 +01:00
Zbigniew Jędrzejewski-Szmek d5c30300da
Merge pull request #13962 from keszybz/man-ordering
Describe ordering in case of Conflicts=
2019-11-08 10:18:46 +01:00
Zbigniew Jędrzejewski-Szmek 38c432b37c man: describe ordering in case of Conflicts=
Fixes #13421.
2019-11-08 10:17:27 +01:00
Zbigniew Jędrzejewski-Szmek d19cd71a8a man: put description of Wants= above Requires=
We want users to use Wants, but we'd describe Requires first and ask users to
look for Wants instead. While at it, let's split the wall of text into sensible
paragraphs: syntax first, followed by semantics and longer description, and
finally hints and comparison to other configuration items last.
2019-11-06 22:39:03 +01:00
2 changed files with 78 additions and 68 deletions

View File

@ -560,22 +560,44 @@
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>Configures requirement dependencies on other units. If this unit gets activated, the units
listed here will be activated as well. If one of the other units fails to activate, and an ordering dependency
<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
stopped. This option may be specified more than once or multiple space-separated units may be
specified in one option in which case requirement dependencies for all listed names will be created. 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 a unit
<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
<varname>Before=</varname>, then both units will be started simultaneously and without any delay between them
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
<listitem><para>Similar to <varname>Wants=</varname>, but declares a stronger
dependency. Dependencies of this type may also be configured by adding a symlink to a
<filename>.requires/</filename> directory accompanying the unit file.</para>
<para>If this unit gets activated, the units listed will be activated as well. If one of
the other units fails to activate, and an ordering dependency <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
stopped.</para>
<para>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
@ -585,11 +607,7 @@
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>
<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>
without a specific other unit also in active state (see below).</para></listitem>
</varlistentry>
<varlistentry>
@ -610,24 +628,6 @@
</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,15 +676,18 @@
<varlistentry>
<term><varname>Conflicts=</varname></term>
<listitem><para>A space-separated list of unit names.
Configures negative requirement dependencies. If a unit has a
<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>
<listitem><para>A space-separated list of unit names. Configures negative requirement
dependencies. If a unit has a <varname>Conflicts=</varname> setting on another unit, starting the
former will stop the latter and vice versa.</para>
<para>If a unit A that conflicts with a unit B is scheduled to
<para>Note that this setting does not imply an ordering dependency, similarly to the
<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
@ -698,29 +701,36 @@
<term><varname>Before=</varname></term>
<term><varname>After=</varname></term>
<listitem><para>These two settings expect a space-separated list of unit names. They configure ordering
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
start-up is delayed until <filename>foo.service</filename> has finished starting up. Note that this setting is
independent of and orthogonal to the requirement dependencies as configured by <varname>Requires=</varname>,
<varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both
the <varname>After=</varname> and <varname>Requires=</varname> options, in which case the unit listed will be
started before the unit that is configured with these options. This option may be specified more than once, in
which case ordering dependencies for all listed names are created. <varname>After=</varname> is the inverse of
<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
configured unit is fully started up before the listed unit is started. Note that when two units with an
ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is
configured with <varname>After=</varname> on another unit, the former is stopped before the latter if both are
shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other 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 of the two
is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the
start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started
up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished
starting up. Most importantly, for service units start-up is considered completed for the purpose of
<varname>Before=</varname>/<varname>After=</varname> when all its configured start-up commands have been
invoked and they either failed or reported start-up success.</para></listitem>
<listitem><para>These two settings expect a space-separated list of unit names. They may be specified
more than once, in which case dependencies for all listed names are created.</para>
<para>Those two setttings configure ordering dependencies between units. If unit
<filename>foo.service</filename> contains the setting <option>Before=bar.service</option> and both
units are being started, <filename>bar.service</filename>'s start-up is delayed until
<filename>foo.service</filename> has finished starting up. <varname>After=</varname> is the inverse
of <varname>Before=</varname>, i.e. while <varname>Before=</varname> ensures that the configured unit
is started before the listed unit begins starting up, <varname>After=</varname> ensures the opposite,
that the listed unit is fully started up before the configured unit is started.</para>
<para>When two units with an ordering dependency between them are shut down, the inverse of the
start-up order is applied. i.e. if a unit is configured with <varname>After=</varname> on another
unit, the former is stopped before the latter if both are shut down. Given two units with any
ordering dependency between them, if one unit is shut down and the other 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
of the two is shut down, as long as one is shut down and the other is started up; the shutdown is
ordered before the start-up in all cases. If two units have no ordering dependencies between them,
they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit
type when precisely a unit has finished starting up. Most importantly, for service units start-up is
considered completed for the purpose of <varname>Before=</varname>/<varname>After=</varname> when all
its configured start-up commands have been invoked and they either failed or reported start-up
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>

View File

@ -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);
fd = open(devnode, O_RDONLY|O_CLOEXEC|O_NONBLOCK);
if (fd < 0)
return log_device_debug_errno(dev, errno, "Failed to open block device %s: %m", devnode);