[systemd-devel] Problem: Renaming the USB network interface makes SYSTEMD_WANTS not working

[Charles]

All right, well, thank you for you help Andrei.


Sent with Proton Mail secure email.

------- Original Message -------
On Monday, August 29th, 2022 at 7:46 PM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:


> 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 secure email.
> > 
> > ------- Original Message -------
> > On Monday, August 29th, 2022 at 3:19 PM, Andrei Borzenkov arvidjaar at 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.