Bug 133431 - vgremove hang after failed vgremove attempt
vgremove hang after failed vgremove attempt
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Christine Caulfield
GFS Bugs
Depends On:
  Show dependency treegraph
Reported: 2004-09-23 18:49 EDT by Corey Marthaler
Modified: 2010-01-11 21:58 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-29 17:04:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2004-09-23 18:49:14 EDT
Description of problem:
I've seen this quite a few time when bringing up my cluster.

After everyone is in the cman cluster and the clvmd service is in the
run state:

[root@morph-01 root]# cat /proc/cluster/nodes
Node  Votes Exp Sts  Name
   1    1    6   M   morph-01
   2    1    6   M   morph-06
   3    1    6   M   morph-04
   4    1    6   M   morph-03
   5    1    6   M   morph-02
   6    1    6   M   morph-05
[root@morph-01 root]# cat /proc/cluster/services
Service          Name                              GID LID State     Code
Fence Domain:    "default"                           1   2 run       -
[1 3 6 2 5 4]

DLM Lock Space:  "clvmd"                             2   3 run       -
[1 3 2 4 5 6]

I attempt on one of the nodes to vgremove a volume. This causes these
cdrom drive errors along with a failure of the vgremove cmd.

[root@morph-01 root]# vgremove corey
cluster send request failed: Invalid argument

hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54

I then try the remove again and it hangs and the cluster needs to be

I did turn on the cdrom filter in /etc/lvm/lvm.conf and added hdc but
that doesn't seem to help or do anything.
    # Exclude the cdrom drive
    filter = [ "r|/dev/cdrom|hdc" ]

How reproducible:
Comment 1 Corey Marthaler 2004-09-23 19:00:02 EDT
I'm not convinced that the cdrom messages have anything to do with
this bug because even though I always see them right before seeing
this bug I do also see them other times without issue. 
Comment 2 Christine Caulfield 2004-09-24 03:46:51 EDT
yes, the cdrom messages are a red herring. This is a bug introduced by
me fixing a different bug yesterday.
Comment 3 Christine Caulfield 2004-09-24 05:39:02 EDT
it's more complicated than even that. The following checkin fixes
clvmd to cope with more then one VG lock, but there seems to be an LVM
command-line bug in there too. I need to check with agk about that.

Checking in clvmd-cman.c;
/cvs/lvm2/LVM2/daemons/clvmd/clvmd-cman.c,v  <--  clvmd-cman.c
new revision: 1.2; previous revision: 1.1
Checking in clvmd-command.c;
/cvs/lvm2/LVM2/daemons/clvmd/clvmd-command.c,v  <--  clvmd-command.c
new revision: 1.3; previous revision: 1.2
Checking in clvmd.c;
/cvs/lvm2/LVM2/daemons/clvmd/clvmd.c,v  <--  clvmd.c
new revision: 1.3; previous revision: 1.2
Checking in clvmd.h;
/cvs/lvm2/LVM2/daemons/clvmd/clvmd.h,v  <--  clvmd.h
new revision: 1.2; previous revision: 1.1
Checking in cnxman-socket.h;
/cvs/lvm2/LVM2/daemons/clvmd/cnxman-socket.h,v  <--  cnxman-socket.h
new revision: 1.3; previous revision: 1.2
Comment 4 Christine Caulfield 2004-09-27 03:43:33 EDT
This works for me now. Alasdair has given provisional blessing to the
change, but it's in CVS anyhow.
Comment 5 Alasdair Kergon 2004-09-27 06:38:13 EDT
It looks to be the only line that got missed when the locking lines
were converted to use new definitions, LCK_VG_WRITE.
Comment 6 Alasdair Kergon 2004-09-27 06:38:52 EDT
Will be in LVM2 2.00.25.
Comment 7 Corey Marthaler 2004-10-29 17:04:11 EDT
fix verified.
Comment 8 Kiersten (Kerri) Anderson 2004-11-16 14:08:36 EST
Updating version to the right level in the defects.  Sorry for the storm.

Note You need to log in before you can comment on or make changes to this bug.