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.
