test NFS before using it?

[Marc Ahrendt]

how can i test that /net/serverB/whatever is OK before actually running a command like ls against it? the main problem i have is that if the mount is stale or hung up (maybe a NFS bug, timeout, or whatever) my script hangs up.
below is an example of the script i run from serverB

serverB# remsh serverA -l userA -n /net/serverB/export/disk1/home/idt_newcode/bin/node_clean_up/temp/check_node

[harry d brown jr]

nfsstat.

[Marc Ahrendt]

harry: "nfsstat -m" hangs ...which is what i am trying to avoid

i have a server which has NFS all hosed and needs a reboot to fix, so i have this server to test against, and the following commands also hang
bdf, mount, df
so when my cronjob/script runs its ls command against /net/whatever it too hangs, and this is what i am trying to avoid (the cronjob hanging ...not NFS, which i out of my control)

[harry d brown jr]

It sounds more like a disk problem than an NFS problem. Do you have the latest NFS and LVM patches installed on both servers? If not, that is the first step. If you do, try doing a pvdisplay on the device /dev/dsk/dskname or a "dd if=/dev/vgname/lvolname of=/dev/null bs=1024 count=1" to see if it responds.

[A. Clay Stephenson]

Hi Marc:

I would try to fix the underlying NFS problem. Are you running the automounter?

In any event, there is a way to run the commands without hanging and thus answer your specific question. The way to do this is in perl using a signal handler. The basic idea is to set an alarm to fire after a given time. A system call is then made to a command (e.g. nfsstat); if the system call returns, all is well and you issue an alarm 0 to cancel the alarm. However, if the system call does not return the alarm is sent to the process and the signal handler responds and can be used to set an error flag.

See the attached small perl script; this should be very close to what you need.

Regards, Clay

[Marc Ahrendt]

harry: it is definitely a NFS issue, and also you are correct about considering patches
...thx for your quick responses

i know that this system will behave better with respect to NFS if i add the latest patches, but i do not want to add them yet because i was hoping there was a way (and now is a great time for me to test it with this system) to test if NFS is not going to behave correctly BEFORE actually trying to use it

my goal is to make my scripts more robust, along the lines of pinging a sever first before trying to remsh it (i want to "ping" a NFS mount point before using it ...because even with patches there can be a time when the NFS mount is not good)

[Marc Ahrendt]

clay: i am running automounter, and yes my interest is in something like your perl script for NFS. the perl script gave many errors so i think i need to upgrade my perl 5.004_04. my question to you is can the perl script kill the nfstat command if it hangs, or just exit out and say that it is hung (would prefer the nfstat get killed, unless inetd takes it and it is not a resource hog just a wasted entry in the process table)

[A. Clay Stephenson]

Hi Marc:

In that case, I would also check for automounter patches as well. I would cd to /tmp_mnt and look for any strange entries there for clues.

I would definitely upgrade the Perl 5.6.x; 5.6.0 binaries install without any problems; the 5.6.1's usually do. The binaries are available from any on the HP-UX Porting Centers or just follow the links from www.perl.com/CPAN. The short answer is that yes, you could let the signal handler look for the process called within the system call and kill it. This is pretty straightforward in perl. You might consider another command to test your server so that no kill is really needed. I simply chose nfsstat because it eas mentioned earlier. Bear in mind, that if you need to kill this process and it is on a remote box via remsh; the perl script must be on the remote box. I really just gve your the script to serve as a starting point and to illustrate signal handlers - which are just what you need.

Clay

[Marc Ahrendt]

clay: thx for the tips, by the way, the directory that will not even let me do a ll against is /net ..."cd /net: ll" the ll hangs

thx guys, have enough to move forward (perl scripting and NFS/automount patches)

[Bill Hassell · Accepted solution]

Just a note about NFS and reliability: the slightest problem on the network or an NFS server problem affects ALL the clients as if you just yanked a disk out of the cabinet--not good for high reliability servers. Clay's suggestion about using the Perl script to start an NFS query and then killing it if it does not respond is great.

You can also use the standard shell to do this by starting the process in the background, then obtain the process ID, wait for a return code and if nothing, kill the process. Because NFS s really a disk in HP-UX, all the possible ways to access the disk are valid...ll is just as complicated as cd or cp...and they will all hang. Recent patches for NFS on 11.x allow a 'forced' unmount of a bad NFS filesystem.