Hide Forgot
Description of problem: Sometimes when a node restarts during a run of revolver (recovery testing), clvmd will startup will timeout. This causes the volumes to not be activated on that node. Starting cluster: Checking Network Manager... [ OK ] Global setup... [ OK ] Loading kernel modules... DLM (built May 20 2010 11:11:59) installed [ OK ] Mounting configfs... [ OK ] Starting cman... [ OK ] Waiting for quorum... [ OK ] Starting fenced... [ OK ] Starting dlm_controld... [ OK ] Starting gfs_controld... [ OK ] Unfencing self... [ OK ] Joining fence domain... [ OK ] Starting system message bus: [ OK ] Starting Avahi daemon... [ OK ] Starting clvmd: dlm: closing connection to node 5 clvmd startup timed out Version-Release number of selected component (if applicable): lvm2-2.02.65-1.el6.x86_64 lvm2-cluster-2.02.65-1.el6.x86_64 cman-3.0.12-3.el6.x86_64 corosync-1.2.3-1.el6.x86_64 openais-1.1.1-4.el6.x86_64 How reproducible: Usually within 10 iterations of revolver Steps to Reproduce: 1. run revolver with initscripts turned on 2. 3. Actual results: Expected results: Additional info:
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. It has been denied for the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. **
I think this is solved by latest patches which fixes clvmd deadlock. Is this issue still present with 6.0.z packages? If so can you paste clvmd debuglog?
In needinfo for debuglog for 2 months, closing that, The problem is probably fixed but it makes no sense to add it to errata without identifying exact problem. Please reaopen if you hit this again with RHEL6.1 / 6.0.z binaries, thanks.