Bug 384871 - RHEL5 cmirror tracker: create attempt shouldn't create anything if cmirror service is not started
Summary: RHEL5 cmirror tracker: create attempt shouldn't create anything if cmirror se...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cmirror
Version: 5.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jonathan Earl Brassow
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 430797
TreeView+ depends on / blocked
 
Reported: 2007-11-15 15:56 UTC by Corey Marthaler
Modified: 2010-01-12 02:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 21:26:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:0158 0 normal SHIPPED_LIVE new package: cmirror 2009-01-20 16:05:16 UTC

Description Corey Marthaler 2007-11-15 15:56:08 UTC
Description of problem:
To avoid this:
[root@taft-02 ~]# lvcreate -m 1 -L 5G -n mirror taft
  Error locking on node taft-01: device-mapper: reload ioctl failed: Invalid
argument
  Error locking on node taft-04: device-mapper: reload ioctl failed: Invalid
argument
  Error locking on node taft-03: device-mapper: reload ioctl failed: Invalid
argument
  Error locking on node taft-02: device-mapper: reload ioctl failed: Invalid
argument
  Failed to activate new LV.


Version-Release number of selected component (if applicable):
2.6.18-53.el5
cmirror-1.1.0-7

How reproducible:
Everytime

Comment 2 Jonathan Earl Brassow 2007-12-07 17:09:50 UTC
Is it sufficient to auto load the module?

If not, fixing this will be hard.  If so, I have a patch waiting.



Comment 3 Jonathan Earl Brassow 2008-01-16 17:53:36 UTC
patch posted.  Still NEEDINFO if this is sufficient.

Comment 4 Corey Marthaler 2008-01-21 20:38:38 UTC
Even though there is still the case where the module doesn't exit on the
machine, an autoload is better than nothing and is sufficient for this release.

Comment 5 Jonathan Earl Brassow 2008-01-24 15:21:46 UTC
I have verified that the module loads... but that doesn't mean the user has
started the log server (or that the init scripts have been run).


Comment 7 Corey Marthaler 2008-02-05 22:34:29 UTC
FYI - This still doesn't appear to be in cmirror-1.1.9-1.el5.

Comment 8 Corey Marthaler 2008-02-07 23:12:33 UTC
Moving this out of ON_QA state.

Comment 9 Jonathan Earl Brassow 2008-02-08 21:12:49 UTC
this fix does not depend on cmirror, but rather the kernel...  I am running
2.6.18-71.el5xen, and the module load works fine.  Perhaps you are asking for
something else to happen other than module load?


Comment 10 Corey Marthaler 2008-02-08 21:38:35 UTC
I was running 2.6.18-71.el5 as well. If you attempt to create a mirror w/o
cmirror started does it work or do you get the locking error messages? If so is
that because clog isn't started?

Comment 12 Jonathan Earl Brassow 2008-02-13 21:28:46 UTC
Yes, it is because the daemon is not started.


Comment 13 Jonathan Earl Brassow 2008-02-13 21:29:36 UTC
Note that the subject no longer reflects what this bug is...  please change or
close bug.

Comment 14 Corey Marthaler 2008-02-13 23:34:15 UTC
The fact of the matter remains that instead of seeing locking errors and being
left with unusable pieces of a mirror, the lvcreate should just say, "cmirror
service not started" and exit. That would solve all cases, even the one where
the software isn't even installed. There are plently of other places where lvm
will say an operation isn't supported and exit.

Originally I thought that by having the module auto loaded, it would change the
result, but since the end result reamins the exact same, it doesn't matter if
the module gets auto loaded or not if the log daemon isn't started.



Comment 15 Jonathan Earl Brassow 2008-05-02 15:22:01 UTC
Agreed, the problem is still the same.  However, now you get messages in the log
like:
" Userspace cluster log server not found."
This should help a little.  Will leave bug open for better future fix though.


Comment 18 Corey Marthaler 2009-01-07 16:51:47 UTC
This bug should remain open for a possible fix in 5.4.

Comment 19 errata-xmlrpc 2009-01-20 21:26:30 UTC
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 therefore 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/RHEA-2009-0158.html


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