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:
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service"# udevadm monitor | grep -F '(net)'
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)
“Add”, with renaming:
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", NAME="mywifi", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service"# udevadm monitor | grep -F '(net)'
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)
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="" 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
UDEV [24613.969783] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net)
ACTION="">
SYSTEMD_WANTS=test.service
TAGS=:systemd:
UDEV [24614.026461] move /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/mywifi (net)
ACTION="">
TAGS=:systemd:
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:
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)
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:
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", NAME="mywifi”
SUBSYSTEM=="usb", ACTION="" ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}==
"xxxx", ATTRS{idProduct}=="xxxx", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service"
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:
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", NAME="mywifi"Maybe more elegant?
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service"
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
------- Original Message -------
On Monday, August 29th, 2022 at 3:19 PM, Andrei Borzenkov arvidjaar@xxxxxxxxx wrote:
On 28.08.2022 23:35, Charles wrote:
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?
/etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service"/etc/systemd/system/test.service
[Service]
Type=simple
ExecStart=/bin/echo %n started!First try, it works:
I type:# journalctl -f -u test.service
I plug the USB Wi-Fi device and it prints:
"test.service started!"
Note that ip link show returns wlan1.
Now I add NAME="mywifi" which gives:
/etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION="" ATTR{address}=="...", NAME="mywifi", TAG+="systemd", ENV{SYSTEMD_WANTS}="test.service"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.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="">
unless you really want different rules for different uevents.
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,
CharlesSent with Proton Mail secure email.
