On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov <arvidjaar@xxxxxxxxx> 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@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@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.