Re: Problem: Renaming the USB network interface makes SYSTEMD_WANTS not working

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On 29.08.2022 19:38, Charles wrote:
> 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?
> 

Yes.

> 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?

systemd ignores "add" event that renames network interface. One of many
undocumented special cases in systemd code.

Note also that if events are very close, you service may still be
activating and second request to activate it will be ignored.

> 
> 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 

udev does not have any implicit history and each event starts with clean
empty device state. It is possible to import existing attributes with
IMPORT{db}, but in most cases it is more simple to assign them. Import
could be interesting if rule that sets initial value has some side
effects as you want to avoid running it multiple times.

> question is then: why RUN=”/bin/touch /tmp/workiiing” works and is not wiped out? Perhaps it wipes only the ENV?

I am not sure what exactly "works" means here. The "add" event creates
some file and of course this file is not removed by further events.
Whatever happens in RUN is completely unknown to udev.

> How could I see what you called the "udev device state"? to know if it's actually been wiped out.

udevadm info

> 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?

It does not matter what I think. The code was there for years. To change
it now you need to have very good reasons. And I am pretty sure that
such change will break at least some existing rules.

> 
> 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?

ACTION!="remove" handles any event that may be added to kernel later.

> 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 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=="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.