Bug 2176919
| Summary: | INFO: task systemd-udevd:20742 blocked for more than 122 seconds. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Martin Hoyer <mhoyer> |
| Component: | iscsi-initiator-utils | Assignee: | Chris Leech <cleech> |
| Status: | NEW --- | QA Contact: | Storage QE <storage-qe> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.3 | CC: | agk, bmarzins, heinzm, msnitzer, nanliu, prajnoha, zkabelac |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Martin Hoyer
2023-03-09 16:29:07 UTC
So I suspect it was caused by the iSCSI initiator trying to connect to a target which it had no network path to. After running `iscsiadm -m discovery -t st -p 172.16.0.20 -I qedi0` 172.16.1.20:3260,1 iqn.1994-05.com.redhat:stqe-lio 172.16.0.20:3260,1 iqn.1994-05.com.redhat:stqe-lio `iscsiadm -m discovery -t st -p 172.16.1.20 -I qedi1` 172.16.1.20:3260,1 iqn.1994-05.com.redhat:stqe-lio 172.16.0.20:3260,1 iqn.1994-05.com.redhat:stqe-lio target will provide two portals for each interface, however the 172.16.1 is not reachable by qedi0 and 172.16.0 is not reachable by qedi1. So when user instead of specifying a portal and interface simply runs `iscsiadm -m node -l`, timeouts will arise and this call trace can be reproduced. Reassigning to iscsi-initiator-utils based on comment #1. Assuming that the multipath device was set to queue_if_no_path, this is exactly what you'd expect if you had no paths to your device. I'm not sure that there's actually a bug here. But if there is, and it further investigation points to multipath, feel free to reassign it back. Hi, I reported one similar bug on RHEL8.9 with high reproducibility: Bug 2217866 - [RHEL8.9] INFO: task systemd-udevd:2691 blocked for more than 120 seconds with over 256 vcpus, please check. |