Bug 2143719
| Summary: | numad freezes during multiple access | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ajeco Support <support> |
| Component: | numad | Assignee: | Lukáš Nykrýn <lnykryn> |
| Status: | CLOSED MIGRATED | QA Contact: | qe-baseos-daemons |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.6 | CC: | dag |
| Target Milestone: | rc | Keywords: | MigratedToJIRA |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-21 09:56:19 UTC | 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: | |||
Actually therea are two flaws in numad: 1. Only the daemon should flush the queue at init 2. There should be a timeout mechanism in the recieve message from ipc function It should also be considered if there is a risk of the first invocation wrongly being seen as a daemon if we have multiple concurrent numad -w invocations. Havenät had the time to look into the daemon detection code. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |
Description of problem: numad -w will occasionally freeze if invoked concurrently with the numad daemon running Version-Release number of selected component (if applicable): 0.5-26.20150602git How reproducible: Always Steps to Reproduce: 1.Execute numad -w 4:4096 from multiple concurrent sessions. A good command line is: while true; do numad -w 4:4096; numad -w 4:4096; numad -w 4:4096; done 2.Wait for some time. Perhaps restart the command sequence to create a suitable timing skew. 3. Actual results: You will see one of the sessions freezing after a while Expected results: The sequence should run smoothly Additional info: This problem appeared during concurrent migration of several (n>3) VM:s in a KVM cluster. The VM:s had a numatune section looking like this: <vcpu placement='auto'>8</vcpu> <numatune> <memory mode='strict' placement='auto'/> </numatune> libvirt tried to use numad -w 8:4096 to figure out the placement and the freeze of numad would also freeze libvirtd, which led to pcs rebooting the node. Looking at the source of numad it seems like the potential problem is that each instance of numad will run init_msg_queue() at invocation. As this also does a flush_msg_queue() the queue will be emptied at every invocation. If this happens in the middle of the send/rcv-sequence of another invocation the other process will never get an answer and hang.