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=="add", 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=="add", 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==”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
> 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:
> 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:
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=="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"
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=="add", ATTR{address}=="...", NAME="mywifi"
> SUBSYSTEM=="net", ACTION=="move", ATTR{address}=="...", TAG+="systemd",
> ENV{SYSTEMD_WANTS}="test.service"
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
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Monday, August 29th, 2022 at 3:19 PM, Andrei Borzenkov arvidj...@gmail.com
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=="add", 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=="add", 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=="add"
>
> 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,
>> Charles
>>
>> Sent with Proton Mail secure email.
