<div style="font-family: Arial; font-size: 14px;">Hello Andrei! I'm French, thank you for helping me out! You helped me to make progress! Your proposition worked and I found 2 other solutions. Unfortunately, I still think it's a bug. Here’s the details with some questions if you have time: “Add”, without renaming: <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="...", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service" </blockquote> # udevadm monitor | grep -F '(net)' <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> KERNEL[17484.646799] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/wlan1 (net) UDEV [17484.695897] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/wlan1 (net) </blockquote> “Add”, with renaming: <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="...", NAME="mywifi", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service" </blockquote> # udevadm monitor | grep -F '(net)' <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> KERNEL[17653.052434] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/wlan1 (net) KERNEL[17653.088350] move /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net) UDEV [17653.116958] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net) UDEV [17653.179020] move /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net) </blockquote> Would it be because of the “move” event? Thank you, using ACTION!="remove" as you suggested works (both with and without rename). Is there a documentation I need to read? Because I do not understand the real difference between ACTION==”add” and ACTION!=”remove”. With “remove”, I even imagined it would be triggered multiples time, i.e. when it adds, binds and changes. But it got triggered once (what I wanted). Why? When there is an “add” and “move” event, it’s like !=”remove”, so why the service isn’t triggered twice? You said “rename results in addition uevent which wipes out previous udev device state including SYTSEMD_WANTS”. Are you saying that if there is the “add” event, and then quickly after the “move” event, the “add” event get wiped out? The question is then: why RUN=”/bin/touch /tmp/workiiing” works and is not wiped out? Perhaps it wipes only the ENV? How could I see what you called the "udev device state"? to know if it's actually been wiped out. Where did you learn the use of ACTION!="remove" a better practice? It works, but sounds odd? The software should be developed to make “add” work, no? With the “add” rule, running the following command helped me to better see what’s happening: # udevadm –udev –property <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> UDEV [24613.969783] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net) ACTION=add SYSTEMD_WANTS=test.service TAGS=:systemd: </blockquote> <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> UDEV [24614.026461] move /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net) ACTION=move TAGS=:systemd: </blockquote> I noticed “SYSTEMD_WANTS=test.service” got removed from the “move” event. The proper solution would be that the “move” event inherit the properties. How to do that? To my opinion, systemd-udev’s code should be updated so that properties are not erased when renaming. What do you think? Since I was not so convinced by the mysterious use of ACTION!=”remove”, I had an idea. I notice a common output. Renaming or not, it prints the same: <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> UDEV [18194.419026] add /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb) UDEV [18194.424387] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb) UDEV [18194.494285] bind /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb) UDEV [18194.514986] bind /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb) </blockquote> So I put a rule for that parent device instead: # udevadm info --attribute-walk /sys/devices/pci0000\:00/0000\:00\:14.0/usb1/1-3/ | less And I end up with these two rules: <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="...", NAME="mywifi” SUBSYSTEM=="usb", ACTION=="bind", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}== "xxxx", ATTRS{idProduct}=="xxxx", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service" </blockquote> And it also works. The problem is that I’ll need to pass the name of the interface to the service and start wpa_supplicant, so that solution is not elegant. It should be triggered by the “mywifi” device and not a parent device. Another solution is: <blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="...", NAME="mywifi" SUBSYSTEM=="net", ACTION=="move", ATTR{address}=="...", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service" </blockquote> Maybe more elegant? I don’t exactly know when the “move” event would be triggered. I guess it’s driver specific. And there are no documentation about it. Sounds stable enough. But still, do renaming an interface should erase its properties (e.g. ENV{SYSTEMD_WANTS})? Isn’t that a systemd-udev bug? Thank you,Charles <div class="protonmail_signature_block" style="font-family: Arial; font-size: 14px;"> <div class="protonmail_signature_block-user protonmail_signature_block-empty"> <div> </div> </div> <div class="protonmail_signature_block-proton"> Sent with <a target="_blank" href="https://proton.me/" rel="noopener noreferrer">Proton Mail</a> secure email. </div> </div> ------- Original Message ------- On Monday, August 29th, 2022 at 3:19 PM, Andrei Borzenkov <a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a> wrote: <blockquote> On 28.08.2022 23:35, Charles wrote: <blockquote> Hello, Adding NAME="mywifi" to an udev rule causes the SYSTEMD_WANTS service to not be executed. Removing NAME="mywifi" and the service is executed. How come? <blockquote> /etc/udev/rules.d/10-network.rules SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="...", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service" </blockquote> /etc/systemd/system/test.service <blockquote> [Service] Type=simple ExecStart=/bin/echo %n started! </blockquote> First try, it works: I type: <blockquote> # journalctl -f -u test.service </blockquote> I plug the USB Wi-Fi device and it prints: <blockquote> "test.service started!" </blockquote> Note that ip link show returns wlan1. Now I add NAME="mywifi" which gives: <blockquote> /etc/udev/rules.d/10-network.rules SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="...", NAME="mywifi", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service" </blockquote> I plug the USB Wi-Fi device and it prints nothing. Note that ip link show returns mywifi. I remove NAME="mywifi" and it prints "test.service started!" again. </blockquote> My best guess is that rename results in addition uevent which wipes out previous udev device state including SYTSEMD_WANTS. Try "udevadm monitor" to see the difference. General consensus is that you should use ACTION!="remove" instead of explicit ACTION=="add" unless you really want different rules for different uevents. <blockquote> I really do not understand. When using RUN, it works all the time. SYSTEMD_WANTS seems to work only when the interface is not renamed. I tried also to rename it with a .link file, it got renamed but the service is still not triggered. Hope you can help me out. Thanks in advance for your time, Charles Sent with Proton Mail secure email. </blockquote> </blockquote></div>