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. >