On 9/24/25 13:46, Mantas Mikulėnas wrote: > On Wed, Sep 24, 2025 at 8:27 PM Demi Marie Obenour <[email protected]> > wrote: > >> There are cases where a RUN+= script needs to do something >> exactly once each time a device appears, such as binding a >> different driver to the device. If the udev rule matches >> based on a property (such as PCI device information) that >> is set only by the kernel, is it okay to use ACTION=="add" >> in the rule? The only other options I know of are to either >> > > Such events can still be caused by the admin doing "udevadm trigger > --action=". Not sure why one might do that, but probably better to not rely > on nobody doing that.
In *this* case that should never happen, as Spectrum OS's host
is basically an appliance and ideally nobody would be able to
run commands like that.
Will an ACTION=="add" event always come before any other events?
>> 1. Add additional code to the script to make sure it is
>> idempotent. This might require adding a lock.
>>
>
> Maybe not necessarily a lock as I *think* udev event processing is
> serialized (for a given device at least); a flag file in /run or an xattr
> on the /dev node might be enough.
These are PCI devices with no driver. The difficulty with a flag file
is that it needs to be reliably removed.
>> 2. Use a persistent daemon.
>>
>
> It might be possible to have a persistent Type=oneshot .service via
> ENV{SYSTEMD_WANTS}, with RefuseManualStop. Not sure if that's a good idea.
I'm not using systemd as PID 1, so this definitely isn't an option :).
It seems that a persistent daemon is the technically correct way to
do this, but it's a lot of extra complexity. That's unfortunate,
but it somewhat makes sense.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
