Arch Linux

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?

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.

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.

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.

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.

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.

aufs in the base system is a bad idea. For the rest, see  FS#18157 .

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.

@Infin1ty: Look at  FS#18157 , there is a discussion about putting /var/{lock,run} to an tmpfs.

@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.

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?

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.

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.

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.

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?

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?

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

So when is it supposed to be integrated in the official package(s)/repo(s) ;)?

This is already in testing, could probably be moved to core.