Udev rule processing waits until RUN finishes. So for example systemd
.device units won't become "ready" until all rules for that particular
event – including their RUNs – are finished and until udev emits its own
'add' event; likewise userspace services that use libudev won't "see" the
device until then.

So if the tool/helper actually prepares the device for use, then it often
makes sense to RUN it directly (even if it takes a second or two to finish)
in order to get the device ready for use before udev sends out its own
"final" add event.

On the other hand, if the helper does the opposite and merely starts
something that'll *use* the device (like a monitoring service), then it
should be asynchronous via systemd-run or SYSTEMD_WANTS or similar.

The default timeout before a udev worker is killed seems to be 3 minutes.
I'd probably aim for 5-10 seconds maximum? (I think workers are shared so
if a rule takes long it might block processing of other events?)

On Thu, Jul 17, 2025, 17:49 Anthony Rossomano <trosso...@gmail.com> wrote:

> Yeah, that’s what I’m thinking as well. I was just concerned about running
> a program directly from RUN as I know it needs to be “short lived” but not
> sure what that means in practice. That’s why I thought about splitting it
> out, with at, etc
>
> On Jul 17, 2025, at 7:40 AM, Mantas Mikulėnas <graw...@gmail.com> wrote:
>
> 
> If you need multiple instances, you could also use `systemd-run` to create
> in-memory .services, a bit similar to `at` but without having to rely on
> atd being installed (some systems no longer have it).
>
>     RUN+="/bin/systemd-run --quiet /usr/lib/udev/some_dev_handler %k"
>
> But it sounds like your services are really short-lived (if their job is
> just setup/teardown) and would be better called synchronously from RUN
> without going through systemd at all?
>
> On Thu, Jul 17, 2025, 17:20 Anthony Rossomano <trosso...@gmail.com> wrote:
>
>> Understood. Looking for some advice on how to distinguish udev event
>> (add/remove) for device that spontaneously restarts (e.g. due to power
>> issue, etc) and device restart that is manually triggered via GPIO.
>> There is teardown that needs to be done when device resets, and this
>> involves manually restarting the device using GPIO.
>>
>> Have tried starting systemd oneshot service on both the add and remove
>> and trying to resolve timing issues. Systemd ensures that the two
>> instances of the service cannot be running concurrently, so that is
>> covered. But we have the case where the first service stops around the
>> time the second is started due to manual restart of the device and
>> there would be no action to perform but not sure how to detect that
>> case.
>>
>> On add event we started the service using SYSTEMD_WANTS tag in udev add
>> rule.
>>
>> Also have tried using the remove event and starting the service using
>> systemctl --no-block
>>
>> Thought about using rate limiting in the service but that isn't
>> sufficient.
>>
>> Also thought about using flag file but there are cases where stale
>> file could remain.
>>
>> Seems like best option might be to not use systemd service and start
>> our recovery program from udev rule using "at" to run outside of udev
>> processing.
>>
>> Any other possibilities here?
>>
>> On Sun, Jul 13, 2025 at 10:23 PM Mantas Mikulėnas <graw...@gmail.com>
>> wrote:
>> >
>> > There is only ever a single instance of a unit with a specific name,
>> since the name is how you control it.
>> >
>> > If multiple instances are needed, they need to have unique names,
>> usually through a template unit (foo@.service → foo@
>> $env{something}.service).
>> >
>> > On Mon, Jul 14, 2025, 06:07 Anthony Rossomano <trosso...@gmail.com>
>> wrote:
>> >>
>> >> I’m starting an oneshot systemd service from udev remove event and
>> wanted to confirm the expected behavior if an instance of service is
>> running and another service start is attempted. From my trials it appears
>> that the second service is not started if one is already running.
>>
>

Reply via email to