[systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount

[Andrei Borzenkov]

On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov <arvidjaar at gmail.com> wrote:
...
> > Here's the udev rule:
> > ```
> > ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*", ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd", ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment at media-$name.service", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no --options=ro --collect $devnode /media/$name"
> > ```
> >
> > And here's the systemd service:
> > It is templated and gets instantiated with "media-sdb1". It therefore has an "After=media-sdb1.mount". I suspect Systemd-udevd executes the ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence, "media-sdb1.mount" doesn't yet exist when the service gets started, as it gets created a tad later by systemd-mount.
> >
> > ```
> > [Unit]
> > Description=Start standalone Mender deployment (%i)
> > After=%i.mount
> >
> > [Service]
> > Type=oneshot
> > Restart=no
> > ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
> > ```
> >
...
>
> Hmm ... if systemd-mount --property accepts Wants and Before, your
> mount unit could pull in your service unit. I cannot test right now.
>

Yes, this seems to work, so in principle

RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
--options=ro --collect --property
Wants=start-standalone-mender-deployment at media-$name.service $devnode
/media/$name"

is possible. Unfortunately this starts unit even if mount fails and
systemd-mount does not accept RequiredBy property". It is still
possible to add Requires to service itself.

[Unit]
Description=Start standalone Mender deployment (%i)
After=%i.mount
Requires=%i.mount

This will fail the service start job if the mount job fails.

Wants on mount unit pulls in service, so we are guaranteed to always
have both start jobs - for mount and for service and dependencies are
observed.