On Mo, 26.10.20 11:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > So the ultimate quesiton is: what kind of trigger was executed on my > > device on boot time? > > > > Hi, > > FWIW, I was totally baffled by a similar problem with a DRM device. My > rule was doing the same thing: match to "add" and skip otherwise. My > rule did not appear to take effect at boot. > > The problem was not that "add" was not emitted - it was and processed > with my rule. The problem was that the DRM driver then shortly after > emitted also "changed" (this is how DRM communicates monitor hotplug > events). Because my rule did not match "change", the udev property I > was adding was effectively *removed*. IOW, any monitor hotplug would > cause my udev setting to disappear. > > Therefore I concluded that if you want your rule to apply always (e.g. > set a property that you expect to always find on the device), do not > filter it with ACTION at all. New actions could be added any time, and > then your rule breaks. At most, maybe it is safe to skip if > ACTION=="remove", but I'm not sure about even that.
That is the correct way: check for the one "negative" action type (i.e. "remove"), and run your rules on all the other action types, i.e. on all "positive" action types. (Where "positive" means: the device exists and is there, and (mostly) useable, and "negative" means: the device doesn#t exist anymore) Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
