Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2685 - Coldplug too soon; hotplug.d scripts not run for some events #7484

Open
openwrt-bot opened this issue Dec 18, 2019 · 8 comments
Open
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release

Comments

@openwrt-bot
Copy link

cshoredaniel:

OpenWrt 19.07.0-rc2, latest openwrt-packages.

Occurs on at least ath79 but looking at the code this is not device-specific.

  1. Have USB devices for which you have hotplug scripts (e.g. from p910d and sane-backends)
  2. Boot (or reboot) with usb devices already plugged in.
  3. Observe that the actions in the hotplug script (e.g. setting permissions / group ownership that don't belong in the base system (i.e. hotplug.json)) as it'd be bloat to detect product:vendor ip pairs and take appropriate action for all the various packages and devices hotplug handles -- if hotplug.json could have hotplug.json.d or somesuch it would alleviate most of this pain.

Looking at the procd code coldplug (udevtrigger) is called during 'early' init, which means that hotplug.d scripts are not yet present. Because /etc/init.d/boot (or any other initscript) no longer does a later call to udevtrigger, the events get missed).

If udevtrigger were called during regular init this wouldn't be an issue (but probably the coldplug is needed earlier as well for devices needed to boot the system.

See also #1903 and #996 (they are likely the same root cause).

@openwrt-bot
Copy link
Author

cshoredaniel:

Also running udevtrigger manually causes the hotplug scripts to run correctly.

@openwrt-bot
Copy link
Author

Ogura:

What sort of only "some" devices it are?
I mean which are triggering and which do not?
May it be the same with my FS#2641 ?
By the way, my modem did not appear as /dev/ttyUSB* devices neither nor as hot plugged nor during during booting.

@openwrt-bot
Copy link
Author

cshoredaniel:

It's a race condition so it depends on when the system 'decides' to enumerate the device. If the device is detected by the kernel too quickly, then it only gets early init coldplug event and not the full hotplug.json with a root fs.

So it's not a specific type of type device, although USB is probably what most OpenWrt users will notice this with (because it's where most non-platform devices would be added to the system).

Yes it almost certainly is the same as https://bugs.openwrt.org/index.php?do=details&task_id=2641.

Not showing up in /dev is a symptom of the issue; check ''dmesg'' output and see if shows up there (i.e. if there kernel detected early in the boot).

@openwrt-bot
Copy link
Author

cshoredaniel:

In the past ''udevtrigger'' was run during the ''/etc/init.d/boot'' script but IIRC that also caused (different) issues with duplicate hotplug events.

@openwrt-bot
Copy link
Author

luizluca:

Related/Duplicated FS#1903, FS#996

@openwrt-bot
Copy link
Author

luizluca:

At least for sane-backends, the hotplug was running as expected. However, it was running before logger could send logs. So, all outputs got lost. I changed that output to /dev/kmsg to be able to read hotplug msgs. It would be nice if OpenWrt could keep logs from early stage.

The only issue with sane-backends hotplug script was that it ran before usblp module was loaded. So, it could not grant the needed access.

I just pushed a fix for that (while updating sane-backends too). Now it grants the same access when a device using usblp is plugged.

openwrt/packages@0a85579

After that, at least for p910nd and sane-backends, I could not reproduce any hotplug issue during boot.

Daniel Dickinson, could you test if the new hotplug script fixes your issue (it can be used with an older sane version)?

@openwrt-bot
Copy link
Author

cshoredaniel:

Ah! Thanks for looking into this, I was barking up the wrong tree. I will do a test later this week.

@openwrt-bot
Copy link
Author

cshoredaniel:

I can confirm this solves the problem I was having. I guess this will have to be de-duplicated from the other issues. This may be similar to the other issues in root cause, but it may taking examining each individually. Probably the most import hint is to know that logging doesn't include some early events.

Thanks again!

@aparcar aparcar added the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release
Projects
None yet
Development

No branches or pull requests

2 participants