On Tue, Jul 13, 2021 at 4:06 PM Andrei Borzenkov <arvidj...@gmail.com> wrote:
>
> On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither <man...@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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
