Urgent kill make_sys_image

[Luke Bell]

Hi

I am surrently running a make_net_recovery to a central ignite server. This was supposed to be a very quick image and so was done on line. the server being backed up is our production system. however someone has loaded about 30 GB of info onto VG00 and the ignite image is slowing down the network sonsiderablly.

when I try to stop the backup it says kill make_sys_image on the client.

I ve looked and there are four make_sys_image processes:


root 2202 2158 0 12:21:16 pts/tb 0:00 /usr/bin/sh /opt/ignite/data/scripts/make_sys_image -d /var/opt
root 2200 2158 0 12:21:16 pts/tb 0:00 /usr/bin/sh /opt/ignite/data/scripts/make_sys_image -d /var/opt
root 897 29397 0 12:20:33 pts/tb 0:00 /usr/bin/sh /opt/ignite/data/scripts/make_sys_image -d /var/opt
root 2199 2158 0 12:21:16 pts/tb 0:56 /usr/bin/sh /opt/ignite/data/scripts/make_sys_image -d /var/opt


If i just kill them then do all the nfs mounts sort themselves out or are there other actions necessary after killing them. I dont want to have our production server to be the first one i try this on blind.

BTW what the best way to kill these processes?

Thanks in advance

Luke

[Bill Hassell · Accepted solution]

As far as killing the processes, start with a simnple kill or kill -15 plus the list of all the processes. If that doesn't do it, try kill -1 and finally, use kill -9. Because these are fairly specialized network processes, they may trap and ignore kill -15. NFS should be unaffected.

As far as 30Gb on VG00, that is definitely not recommended. Eeven if you are stuck with internal disks that are 72Gb in size, keep VG00 to just 2-3Gb, enough for the opsystem and nothing else. The price you pay for trying to administer massive data structures on VG00 isn't worth the unused space on a big disk. Always keep application and database file on separate volume groups.

Technically, you run make_net_recovery with exlude options to leave off the extra data which will get you going for now.

[Steven E. Protter]

Try this pattern matching script.

See attached.

SEP

[Luke Bell]

Hi Bill

If I kill those process theres still the nfs mounted filesystems of

/var/opt/ignite/recovery/arch_mnt
/var/opt/ignite/recovery/client_mnt

do i just unmount these on the client?

[Luke Bell]

sorry its fine now,

after killign the processes the attempt was made to unmount the filesystms but this errored as they were busy ive just manually done it and it works.

thanks


btw the 30GB is a tempoary fs where a loads of cds have be copied for an application installtion.

[Luke Bell]

this isnt my day

iam trying to unmount one of the nfs file systems and i ge the following error

umount /var/opt/ignite/recovery/arch_mnt
nfs umount: nfs_unmount: /var/opt/ignite/recovery/arch_mnt: is busy
umount: return error 1.

any ideas?

[Bill Hassell]

Probably the most common error message there is for NFS. You (or other users) have probably cd'd into the NFS mount point (never a good idea). When you cd into a directory, the directory is opened which prevents un-mounting the directory (you'd be removing the disk, leaving the user in limbo). Try this:

fuser /nfs_mountpoint

If you get a list of processes, then track down the owner and have them cd someplace else or stop running a process that is read/writing files on that NFS mountpoint. If fuser does not return anything (somewhat common), you'll need to get a copy of lsof to track down the processes that are holding the disk open. lsof is available from http://hpux.connect.org.uk/

[Sanjay_6]

Hi Luke,

Try this link,

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000070309201

This is itrc doc id UIUXKBRC00013210

Hope this helps.

Regds

[Luke Bell]

hi

all thanks for your responses, whilst trying to track down the processes i tried to unmount the file system again a few times eventually it allowed me to unmount it with out goign anything.

this seemes an incrediably messy way of stopping an ignite image. but at least it seems to eb ok.

thanks again