Bug 159965
Summary: | Cluster Management window does not refresh after configuration change and traceback | ||
---|---|---|---|
Product: | [Retired] Red Hat Cluster Suite | Reporter: | Paul Kennedy <pkennedy> |
Component: | redhat-config-cluster | Assignee: | Jim Parsons <jparsons> |
Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | adstrong, cluster-maint, jha, kupcevic, mihai.ibanescu |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2006-0198 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-03-09 19:49:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Paul Kennedy
2005-06-09 19:30:58 UTC
Fixed in Errata Candidate I have still hit this assert a couple of times today while playing around with starting and stoping and moving around services. I can't pinpoint what exactly causes this though because it usually works. Spurious OS signal error in waitpid attempt Traceback (most recent call last): File "/usr/share/system-config-cluster/MgmtTab.py", line 232, in onTimer self.prep_tree() File "/usr/share/system-config-cluster/MgmtTab.py", line 182, in prep_tree nodes = self.command_handler.getNodesInfo(self.model_builder.getLockType()) File "/usr/share/system-config-cluster/CommandHandler.py", line 252, in getNodesInfo out,err,res = executil.execWithCaptureErrorStatus("/sbin/cman_tool",args) File "/usr/share/system-config-cluster/executil.py", line 20, in execWithCaptureErrorStatus return __execWithCaptureErrorStatus(BASH_PATH, [BASH_PATH, '-c', command]) File "/usr/share/system-config-cluster/executil.py", line 91, in __execWithCaptureErrorStatus (pid, status) = os.waitpid(childpid, 0) File "/usr/share/system-config-cluster/ForkedCommand.py", line 133, in serviceSignalHandler if(reaped == EXT_PID): UnboundLocalError: local variable 'reaped' referenced before assignment Fixed in 1.0.16 Not sure if this is the exact same bug but I was doing the same senario (playing around with serivces; start and stopping...) and I hit this similar traceback: Traceback (most recent call last): File "/usr/share/system-config-cluster/MgmtTab.py", line 234, in onTimer self.prep_service_tree() File "/usr/share/system-config-cluster/MgmtTab.py", line 205, in prep_service_tree services = self.command_handler.getServicesInfo() File "/usr/share/system-config-cluster/CommandHandler.py", line 327, in getServicesInfo out,err,res = executil.execWithCaptureErrorStatus(clustat_path,args) File "/usr/share/system-config-cluster/executil.py", line 20, in execWithCaptureErrorStatus return __execWithCaptureErrorStatus(BASH_PATH, [BASH_PATH, '-c', command]) File "/usr/share/system-config-cluster/executil.py", line 72, in __execWithCaptureErrorStatus i,o,e = select.select(in_list, [], []) select.error: (4, 'Interrupted system call') If this is a different bug, let me know and I'll close this one and open a new one. This traceback is a different bug, but since it also originates from the code that executes shell commands, it fits under the same umbrella. Shouldn't python's select.select() take care of EINTR, and enter select() syscall again? See traceback in comment #4 Adding misa to CC I can check for EINTR in s-c-cluster; just wondering if exception on EINTR is expected behavior. FYI: hit this again today while attempting to stop a running service. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-753.html Why was this bug closed? There was never a final "fixed" message. Plus, I just hit this bug again. Fixed in U3 errata build... An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0198.html |