50-udev-default.rules, 41-libsane.rules and others have ACTION checks before manipulate USB GROUP attr like this: ACTION!="add", GOTO="default_end" but 40-gentoo.rules has NOT and attached USB printers gets wrong group settings i guess the problem is in "bind" action from UDEV going last. udevdam monitor -p UDEV [4713.562780] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb) ACTION=add BUSNUM=001 DEVNAME=/dev/bus/usb/001/005 DEVNUM=005 DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 DEVTYPE=usb_device ID_BUS=usb ID_MODEL=Kyocera_ECOSYS_M2540dn ID_MODEL_ENC=Kyocera\x20ECOSYS\x20M2540dn ID_MODEL_ID=06fd ID_REVISION=0000 ID_SERIAL=Kyocera_Kyocera_ECOSYS_M2540dn_VCG8681830 ID_SERIAL_SHORT=VCG8681830 ID_USB_INTERFACES=:070102:070104:ffffff: ID_VENDOR=Kyocera ID_VENDOR_ENC=Kyocera ID_VENDOR_FROM_DATABASE=Kyocera Corp. ID_VENDOR_ID=0482 MAJOR=189 MINOR=4 PRODUCT=482/6fd/0 SEQNUM=2343 SUBSYSTEM=usb SYSTEMD_WANTS=configure-printer@usb-001-005.service TAGS=:systemd: TYPE=0/0/0 USEC_INITIALIZED=13562560 UDEV [4713.563780] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 DEVTYPE=usb_interface ID_VENDOR_FROM_DATABASE=Kyocera Corp. INTERFACE=7/1/2 MODALIAS=usb:v0482p06FDd0000dc00dsc00dp00ic07isc01ip02in00 PRODUCT=482/6fd/0 SEQNUM=2344 SUBSYSTEM=usb TYPE=0/0/0 USEC_INITIALIZED=13563570 UDEV [4713.563867] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1 DEVTYPE=usb_interface ID_VENDOR_FROM_DATABASE=Kyocera Corp. INTERFACE=255/255/255 MODALIAS=usb:v0482p06FDd0000dc00dsc00dp00icFFiscFFipFFin01 PRODUCT=482/6fd/0 SEQNUM=2345 SUBSYSTEM=usb TYPE=0/0/0 USEC_INITIALIZED=13563695 UDEV [4713.564777] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2 DEVTYPE=usb_interface ID_VENDOR_FROM_DATABASE=Kyocera Corp. INTERFACE=255/255/255 MODALIAS=usb:v0482p06FDd0000dc00dsc00dp00icFFiscFFipFFin02 PRODUCT=482/6fd/0 SEQNUM=2346 SUBSYSTEM=usb TYPE=0/0/0 USEC_INITIALIZED=13564571 UDEV [4713.565404] bind /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb) ACTION=bind BUSNUM=001 DEVNAME=/dev/bus/usb/001/005 DEVNUM=005 DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 DEVTYPE=usb_device DRIVER=usb ID_BUS=usb ID_MODEL=Kyocera_ECOSYS_M2540dn ID_MODEL_ENC=Kyocera\x20ECOSYS\x20M2540dn ID_MODEL_ID=06fd ID_REVISION=0000 ID_SERIAL=Kyocera_Kyocera_ECOSYS_M2540dn_VCG8681830 ID_SERIAL_SHORT=VCG8681830 ID_USB_INTERFACES=:070102:070104:ffffff: ID_VENDOR=Kyocera ID_VENDOR_ENC=Kyocera ID_VENDOR_FROM_DATABASE=Kyocera Corp. ID_VENDOR_ID=0482 MAJOR=189 MINOR=4 PRODUCT=482/6fd/0 SEQNUM=2347 SUBSYSTEM=usb TYPE=0/0/0 USEC_INITIALIZED=13562560
I felt adventurous and added two lines to the /lib/udev/rules.d/40-gentoo.rules file. At beginning ACTION!="add", GOTO="gentoo_end" and at end LABEL="gentoo_end" . This change seems to have fixed sys-power/nut not being not able to start upsdrv at all due wrong permissions. Sure, I have only one observation so far... And I don't know if anything has broken from this (other than the change going to be reverted at next update).
i placed file with same modifications in /etc/udev/rules.d/40-gentoo.rules it has higher priority and not to be overwritten on update
can you test eudev-3.2.7 and let me know what you find. i just added it to the tree. thanks.
(In reply to Anthony Basile from comment #3) > can you test eudev-3.2.7 and let me know what you find. i just added it to > the tree. thanks. 3.2.7 doesn't seem to fix the original problem if the 40-gentoo.rules is not modified, at least on my case. I didn't reboot after update, only restarted the service and additionally forced reloading of rules with udevadm. Suddenly though, it seems that there is quite many events when the device is removed or re-plugged, but I haven't yet checked whether that was the case with 3.2.5 too.
(In reply to Anthony Basile from comment #3) > can you test eudev-3.2.7 and let me know what you find. i just added it to > the tree. thanks. bug still present in 3.2.7 need to modify 40-gentoo.rules in the gentoo repo
(In reply to Pavel Khaymi from comment #5) > (In reply to Anthony Basile from comment #3) > > can you test eudev-3.2.7 and let me know what you find. i just added it to > > the tree. thanks. > > bug still present in 3.2.7 > need to modify 40-gentoo.rules in the gentoo repo Can you suggest a patch against 40-gentoo.rules? I'd like to start moving towards stabilization.
Created attachment 557038 [details, diff] Patch for 40-gentoo.rules so that it is run only on "add" event.
Even though this bug report has a patch for the 40-gentoo.rules file which might incidentally work, I somehow smell that this is not a proper solution, because other rules are also executed multiple times. For logs, please check the files I uploaded to https://bugs.gentoo.org/618738 . The VirtualBox rules file is also executed multiple times. While this patch logic might be put there as well to counter this bug, it feels more like a workaround. Additionally, *all* packages that install udev rules files would need to be handled that way, which is... quite difficult to accomplish. The *actual* question from my POV is *why* rules are being processed multiple times. My hunch is that this has to be a bug in eudev, but this said, I haven't tested with systemd-udevd to see how that variant behaves.
(In reply to Mihai Moldovan from comment #8) > Even though this bug report has a patch for the 40-gentoo.rules file which > might incidentally work, I somehow smell that this is not a proper solution, > because other rules are also executed multiple times. > > For logs, please check the files I uploaded to > https://bugs.gentoo.org/618738 . > > The VirtualBox rules file is also executed multiple times. While this patch > logic might be put there as well to counter this bug, it feels more like a > workaround. Additionally, *all* packages that install udev rules files would > need to be handled that way, which is... quite difficult to accomplish. > > The *actual* question from my POV is *why* rules are being processed > multiple times. My hunch is that this has to be a bug in eudev, but this > said, I haven't tested with systemd-udevd to see how that variant behaves. See bug 618738, comment 38 for my answer. It should mostly answer your question and re-iterate what, why and how the patch in attachment 557038 [details, diff] to 40-gentoo.rules would fix the situation. The comment however goes slightly deeper and also presents an alternative fix. My comment was mostly response to the general situation, though, an as such did not answer everything. So here, some answers to rest: - It is totally possible that eudev has bugs and same goes with udev. The behaviour of rule executing and presented events should be same for both forks, though. Thus both eudev and udev would upon attaching an usb-device give you two events when using kernel 4.14 or newer: add and bind. Rules in 40-gentoo would be run twice, and the (in more or less correctly working) other rule would only be run once. Thus giving wrong permissions... > Additionally, *all* packages that install udev rules files would > need to be handled that way, - Indeed. But that actually is how the rules are (or should be) written, so nothing new here. I would say that every rule, unless explicitly done so elsewhere, should match ACTION. p.s. Seems I misspoke in the referred comment of the other bug that who originally suggested the goto-fix. Sorry. p.s.2. The attachment is in patch-form, but the 40-gentoo.rules is actually a file in eudev files-dir, thus the attachment should be interpreted only as a guide to fix the file. The attachment should be not added to the tree.
I also ran into this just now, using =sys-fs/eudev-3.2.9. I wondered why pcscd is segfaulting immediately after plugging a CyberJack device, and debugging it, found that the following happens: - First, "add" is triggered. 40-gentoo sets the "usb" group, then 99-cyberjack sets the pcscd group. - Then, "bind" is triggered. 40-gentoo re-sets the group to "usb", then 99-cyberjack comes, which has the "ACTION!="add"" check, and does not do anything anymore. Finally, pcscd tries to access the device, libusb fails (permission denied) and pcscd crashes. So it seems to me sys-apps/pcsc-lite with basically any USB device and eudev fails without this patch (note that "92-pcsc-ccid" also has the action check). It would be nice to see this patch go into the main tree to fix the issues with nut, pcsc-lite and others.
Hi, I have just switched to eudev. And same issue like other: nut/upsdrv fails to start due to bad permission: chgrp nut /dev/bus/usb/002/007 => is a “good” workaround I will try this patch at my next startup.