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 unti
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, etcOn Jul 17, 2025, at 7:40 AM, Mantas Mikulėnas wrote:If y
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 s
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 rest
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
