[systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?

[Andrei Borzenkov]

On Tue, Jul 13, 2021 at 4:06 PM Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>
> On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither <ManWag at fastmail.fm> 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

I meant Wants and Before of course.

> 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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel