Description of problem: Derek and I are seeing this repeatedly on our nodes when attempting to check for vgs out on the SAN. The vgscan just appears to hang. Here is where the strace shows it's at: stat64("/proc/lvm/VGs/recovery", 0xbffff090) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_SETMASK, ~[RTMIN], [], 8) = 0 write(3, "3\1\377\277\0\0\0\0\0\0\0\0\r\0\0\0\0\1\0V_recovery\0\377"..., 31) = 31 read(3, How reproducible: Always
The latest build seems OK for me. Can you find out what clvmd is up to (clvmd -d) and post the last few lines of the log please. It's also worth disabling debug logging before starting clvmd, as it seems to confuse it's initial LV detection (as I mentioned in email)
I no longer see this vgscan hang but do now see a hang futher down the road at the pvcreate (bz134559).
I'm seeing the vgscan hang again
I'm pretty certain this is the same as the pvcreate hang but until I have any evidence I won't merge the bugs. This is a bit of a long shot, but can you try backing out the last change to clvmd.c: cvs update -r1.3 clvmd.c
Light dawns, yes that would (and does) fix it, for me at least. It seems that combining fork and pthreads is a really bad idea so I've put the fork back to where it was (before any threads are created). Then made the parent wait for daemon initialisation to complete so that it can report errors back to the user. I'll mark 134559 as MODIFIED too as I'm pretty convinced it's the same thing. Checking in daemons/clvmd/clvmd.c; /cvs/lvm2/LVM2/daemons/clvmd/clvmd.c,v <-- clvmd.c new revision: 1.5; previous revision: 1.4 done
fix verified.
Updating version to the right level in the defects. Sorry for the storm.