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