Re: Does After=systemd-udevd.service make my service run after the services started by udev rules?

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither <ManWag@xxxxxxxxxxx> wrote:
>
> 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?
>

No. udevd will queue the start job for my.service. It has no relation
to systemd-udevd.service. If my.service has any ordering dependencies
that cause it to be delayed, it will be delayed. If it does not have
extra ordering dependencies, it is not predictable from practical
point of view when it will be selected for execution. It depends on
details of internal implementation.

Even if another.service is explicitly ordered After my.service it does
not really gurantee anything - another.service may have already
completed when my.service enters queue.

The only way to ensure another.service is always started after
my.service is to make my.service Want and After another.service and
make sure nothing else can cause start job for another.service to be
queued.


> 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
> systemd-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel