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
Is it sufficient to auto load the module? If not, fixing this will be hard. If so, I have a patch waiting.
patch posted. Still NEEDINFO if this is sufficient.
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.
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).
FYI - This still doesn't appear to be in cmirror-1.1.9-1.el5.
Moving this out of ON_QA state.
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?
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?
Yes, it is because the daemon is not started.
Note that the subject no longer reflects what this bug is... please change or close bug.
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.
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.
This bug should remain open for a possible fix in 5.4.
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