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?