Stuck "vgscan" process

[Aurel Prisecaru]

Hi,

After a switch from a FC10 mirror-failed SCSI disk to a XP512 disk (containing Oracle .dbf files), on a V-Class, I made the stupid mistake of issuing a vgscan command out of confusion (thought the contents of /etc/lvmtab changed when we changed we made the mountpoint switch! Stupid me!!!).

The problem is that the vgscan never returned the prompt. I made a backup of /etc/lvmtab file prior to issuing the "vgscan" command yet I forgot to delete the old /etc/lvmtab file. The vgscan appears as still running when "ps -ef | grep vgscan" and no kill $PID or kill -9 $PID would stop it! All the other processes on the server (mainly 4 Oracle instances) are working fine for now and the system looks stable.

My questions would be:
1) How will an uncompleted "vgscan" command affect the machine (16procs, 16gb RAM) and the running database and will there be any problems in the future when issuing other I/O extensive commands such as "ioscan -funC disk"?
2) Should the machine be rebooted?(worst choice as it's the main production server...)

P.S. My 2c ... I think "vgscan" might have got stuck while scanning the FC controller on the XP512 or most probably on the FC10 FC controller where STM still reports the failed drives (not yet taken out of LVM configuration!)

Any help will be highly apreciated by my already in-pain head and stomach!

Regards,
A.P.

[RAC_1]

what exactly you did???

Kill the vgscan. Move the old lvmtab to /etc/lvmtab.

Anil

[G. Vrijhoeven]

Hi AP

The vgscan will remain running until the server is rebooted or untile the failed drives start responding again. If you have some spare space on you xp512 you should be able to configure the luns you are missing. So if you remember the ldev/lun numbers this remains an option.

I do not know if I/O scans are affected or if it is a couse for an immediate reboot.

But maybe recreating the disks the server si missing will solve pyour problem.

Regards,

Gideon

[Sundar_7]

I dont know if this is going to help. But how about disconecting host connections to the FC10 and see if that makes the vgscan terminate bit faster ?

If it is not responding to kill -9, then the process is struct waiting for some IO to complete (most probably waiting for the response from the failed drives).

I dont believe STM comes in to picture at all here.

If disconnecting host connections donot help, then I am afraid, only way to get rid of the process is to reboot.

[Aurel Prisecaru]

to RAC: "...no kill $PID or kill -9 $PID would stop it!" So I can't kill the beast in any know way!
to G. Vrijhoeven: the disks are just fine right now as we have succesfully made the switch between the already added to the /etc/lvmtab disk from FC10 to XP512 (that's where my stupidity in re-issuing an useless "vgscan" comes from!). I am more concerned about long term server stability and if there's any way of getting rid of that still-running "vgscan".

I am still in doubt whether to proceed with taking out of LVM configs of the old mirror-broken disks and their associated VGs and LVs while the 'vgscan' is still running. Hopefully the reboot is not the only choice!

Regards and lots of thanks,
Aurel

[RAC_1]

vgscan is stuck because, it is looking for the disk from FC30. So untill next reboot you cant do anything. System should be running fine till then.

You may want to have look at vgreduce -f vgxx, will remove the missing disks from a vg.

Anil