Hi all,
when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
another.service with After=systemd-udevd.service, can I at system boot rely on
my.service to be already run when another.service starts?
Here's the background to the question:
I'm developing an embedded device with autoupdate functionality. It grabs the
new disk image from an usb drive when plugged in. The udev rule and the systemd
units + shell scripts run all fine. The only thing complicating all this is
that at boot into the new system, the udev rule fires as well.
I worked around this in the following way:
* udev-triggered start-update.service runs only if
/persistent/update-running.stamp doesn't yet exist. When started, it creates
this file.
* autoscheduled conclude-update.service contains After=systemd-udevd.service
and removes /persistent/update-running.stamp.
I assumed this would at system boot ensure the start-update.service to be
started before conclude-update.service, hence not doing anything. Until
recently, this seemed to worked fine, but I have received reports making me
believe I was just witnessing a race condition resulting in my favor.
Best regards,
Manuel
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
