Non-idempotent RUN+= scripts

Non-idempotent RUN+= scripts

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 591 bytes --]

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

1. Add additional code to the script to make sure it is
   idempotent.  This might require adding a lock.

2. Use a persistent daemon.

Which of these approaches is best?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [systemd-devel] Non-idempotent RUN+= scripts

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Wed, Sep 24, 2025 at 8:27 PM Demi Marie Obenour <demiobenour@gmail.com>
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.


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


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

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

Re: [systemd-devel] Non-idempotent RUN+= scripts

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1826 bytes --]

On 9/24/25 13:46, Mantas Mikulėnas wrote:
> On Wed, Sep 24, 2025 at 8:27 PM Demi Marie Obenour <demiobenour@gmail.com>
> 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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [systemd-devel] Non-idempotent RUN+= scripts

[Andrei Borzenkov]

24.09.2025 23:46, Demi Marie Obenour wrote:
> On 9/24/25 13:46, Mantas Mikulėnas wrote:
>> On Wed, Sep 24, 2025 at 8:27 PM Demi Marie Obenour <demiobenour@gmail.com>
>> 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.
> 

systemd-udev-trigger.service does it

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

You may try adding device property and importing it in events (IMPORT{db}).