Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#18153 - [lvm2] File-based locking and dmeventd error in 2.02.60-2

Attached to Project: Arch Linux
Opened by Michael Trunner (trunneml) - Wednesday, 03 February 2010, 22:47 GMT
Last edited by Eric Belanger (Snowman) - Sunday, 13 March 2011, 05:44 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Eric Belanger (Snowman)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 24
Private No

Details

Description:
On start up LVM2 gives the following Error Message.

File-based locking initialisation failed.
Child exited with code 5
Unable to start dmeventd.

System works just normal.

Additional info:
* lvm2 package version is 2.02.60-2
* root filesystem is on lvm2 too
* There is now problem when I downgrade to the old version "lvm2 2.02.53"


Steps to reproduce:
Just start Arch Linux with installed lvm2 2.02.60-2.
This task depends upon

Closed by  Eric Belanger (Snowman)
Sunday, 13 March 2011, 05:44 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in initscripts 2011.02.1-1
Comment by Michael Trunner (trunneml) - Wednesday, 03 February 2010, 23:16 GMT
For each of my mirrored LVM-Volumes I get one error of:
> Child exited with code 5
> Unable to start dmeventd.

So when I remove all lvm-mirrors form the volume group it works.
It seems to be that this dmeventd is not started.
Where is the startup script?
Comment by Michael Trunner (trunneml) - Wednesday, 03 February 2010, 23:45 GMT
The Message "File-based locking initialisation failed." is no real error.

In version 2.02.53 it was a verbose output to stdout and with "> /dev/null" nobody has seen it.
Now in version 2.02.60 it is an error output to stderr and "> /dev/null" doesn't work now for this message.
Comment by Michael Trunner (trunneml) - Thursday, 04 February 2010, 00:46 GMT
I found the problem. dmeventd tries to create his pid file. But the root-fs is mounted read-only in this moment so he cannot create that file and exit with exit-code 5.

Source:
dmeventd.h:#define EXIT_OPEN_PID_FAILURE 5


If you run any lvm-commad after the root-fs is mounted read-write, dmeventd starts as it should.
Comment by Michael Trunner (trunneml) - Thursday, 04 February 2010, 02:01 GMT
I found a solution for the dmeventd problem. In rc.sysinit the option --ignoremonitoring has to be added like --ignorelockingfailure and the dmeventd has to be started after var is writeable.

I've created a patch for rc.sysinit.
   lvm2.fix (0.9 KiB)
Comment by Thomas Bächler (brain0) - Thursday, 04 February 2010, 08:08 GMT
Hrm, I am wondering if we should rather mount a tmpfs in /var/{lock,run}/ early in the boot process so that PID files can be written. That way we could have these dmeventd processes running.

As your system works normal, this is not critical, but I guess the dmeventd monitoring is there for a reason, so we should allow it to be started.
Comment by Michael Trunner (trunneml) - Thursday, 04 February 2010, 12:49 GMT
Yes I think the daemon is important and he should running. Whats with an overlay tmp fs for /var/{lock,run} like aufs. Maybe only for the boot process, because some systems don't like when their folder /var/run/<somefolder> is missing. But at all I think it is a good idea to mount an tmpfs, that will reduce the problem of old lock and pid files after a crash or restart.

Anyway, I don't know what happens when the dmeventd is started later or even never, but in the old version of lvm2 (2.02.53) the dmeventd was deactivated, so it can't be so important for a system.
Comment by Thomas Bächler (brain0) - Thursday, 04 February 2010, 13:05 GMT
aufs in the base system is a bad idea. For the rest, see  FS#18157 .
Comment by Erez (Infin1ty) - Friday, 12 February 2010, 08:34 GMT
I was wondering if someone noticed that as well.
If we look at the lvm.conf (/etc/lvm/lvm.conf) we can notice that there's a line to where we can save the lock files, it also mentions that the lock files could be saved on the tmp file system.
I don't think for this issue only (dmeventd) we need to mount /var/{lock,run} as a different fs and make it r/w before mounting the whole file system, perhaps the best idea is to change the lockfile of the lvm into the tmpfs.
Comment by Michael Trunner (trunneml) - Friday, 12 February 2010, 10:43 GMT
@Infin1ty: Look at  FS#18157 , there is a discussion about putting /var/{lock,run} to an tmpfs.
Comment by Erez (Infin1ty) - Friday, 12 February 2010, 11:38 GMT
@trunneml, yes, i know that, but it's seems like putting /var{lock,run} to tmpfs is a bad idea.
as this bug report is lvm specific, perhaps putting the lock dir for lvm specific on a tmpfs is the sulution.
they also state that it's okay to put the lock files on a tmpfs and the option is available on the lvm.conf file.

Comment by Xyne (Xyne) - Saturday, 27 February 2010, 18:42 GMT
I just noticed this for the first time today, so it's obviously nothing critical, but niggling nevertheless.

Has there been any progress in the last couple of weeks?
Comment by Erez (Infin1ty) - Sunday, 21 March 2010, 18:06 GMT
I've managed to create a small solution, perhaps it won't suit for most of the people.
in the lvm.conf there's a comment that says that it's possible to put the lock file on a tmp file system.
so i've added a line in /etc/rc.sysinit which mount /tmp as rw on startup.
/bin/mount -n -t tmpfs none /tmp -o rw,mode=0755
right after the run_hook sysinit_start
it seems to work, no errors what so ever.

Now, it does not matter if the lock file gets deleted after reboot, it's only there to prevent running another lvm command session.

Comment by (N/A) (wantilles) - Saturday, 10 July 2010, 13:55 GMT
File-based locking initialisation failed.

This also happens with the following combination:

device-mapper 2.02.69-1 + lvm2 2.02.69-1 (both were updated in July 9 2010) + kernel26-lts 2.6.32.15-1

And no symlink is created in /dev/mapper/..... and no volume group partitions can be mounted.

With kernel26 2.6.34.1-1 it works normally.
Comment by Michael Gutmann (Gutnix) - Tuesday, 10 August 2010, 12:10 GMT
Well, it becomes definitely a problem, if you use LVM as a raid replacement and have put your root partition mirrored into lvm. Creating a mirrored LV involves the creation of a log partition - which you should put on disk for performance reasons. If dmeventd doesn't work early, it means the log cannot be used and all mirrored LVs get synced immediatly. And this slows booting down heavily.
Comment by Tom Gundersen (tomegun) - Wednesday, 01 December 2010, 11:15 GMT
Further to trunneml's comment: It seems that vgchange has a switch exactly to avoid problems with ro partitions during boot. The manpage says:

--sysinit
Indicates that vgchange(8) is being invoked from early system initialisation scripts (e.g. rc.sysinit or an initrd), before writeable filesystems are available. As such, some functionality needs to be disabled and this option acts as a shortcut which selects an appropriate set of options. Currently this is equivalent to using --ignorelockingfailure, --ignoremonitoring, --poll n and setting LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES environment variable.

I do not use LVM, so I don't know what other changes have to be implemented to follow this, but at least it looks like upstream is aware of the problem and has solved it without requiring partitions to be mounted rw. I guess other distros will have solved the problem, maybe worth a look?
Comment by Tom Gundersen (tomegun) - Thursday, 09 December 2010, 23:12 GMT
This should now be solved in git <http://projects.archlinux.org/initscripts.git/>, could someone who had the problem verify so the bug can be closed?
Comment by Mark Kusch (groover) - Monday, 13 December 2010, 20:46 GMT
Hi,

today I applied patches from git
- b4c804d60d6e8361db3f19bf3a2fa6fb58ee8458 (--sysinit in rc.sysinit and rc.shutdown)
- feef447b8368244525dd98582b662a369098b2f7 (monitoring in rc.sysinit and rc.shutdown)

No further error/warning messages from LVM2.
Everything looks good to me (using luks on lvm2).

With kind regards,

# kraM
Comment by Karol Babioch (johnpatcher) - Thursday, 24 February 2011, 12:45 GMT
So when is it supposed to be integrated in the official package(s)/repo(s) ;)?
Comment by Thomas Bächler (brain0) - Thursday, 24 February 2011, 12:53 GMT
This is already in testing, could probably be moved to core.

Loading...