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)
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.
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)
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}).
participants (3)
-
Andrei Borzenkov -
Demi Marie Obenour -
Mantas Mikulėnas