Summary: | sys-fs/eudev: 40-gentoo.rules overwrite GROUP settings for USB devices | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pavel Khaymi <tenebras609> |
Component: | Current packages | Assignee: | eudev team <eudev> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | ionic, o.freyermuth, sebastien.picavet |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch for 40-gentoo.rules so that it is run only on "add" event. |
Description
Pavel Khaymi
2018-10-17 16:27:06 UTC
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. |