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 ([email protected] → foo@$env{something}.service).
On Mon, Jul 14, 2025, 06:07 Anthony Rossomano
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.
