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
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
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
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
Hello systemd developers,
I'm working on minimizing user space boot time with systemd on an embedded
board and would appreciate any advice or insights from the community.
Setup details:
*
Hardware: sam9x75-curiosity-sd (ARMv5), booting from SD card
*
Distro: Yocto/Poky, custom minimal image
