Dallas Clement wrote: > Okay, I simplified the script slightly, fixed the quoting and re-ran > with set -x. Here is the script and the output for the failure > scenario.
Much more useful! Thanks. > + touch /mnt/array1/.accesstest > + CHK_RESULT=1 It looks to me that touch is failing and reporting the failure and that bash is handling it correctly. > + touch /mnt/array1/.accesstest > + CHK_RESULT=0 And then on a subsequent pass touch is reporting success. This doesn't (yet) look like a problem with bash. > The purpose of this function is simply to try and create or modify a > test file on a RAID share. It's just a periodic integrity check. If I ever had even one single failure on a raid filesystem I would start replacing hardware. I wouldn't be trying to retry. I wouldn't be trying to umount and mount it again. ANY failures would mean something so severely broken that I would consider the system unusable until repaired. On the other hand, do you really mean an NFS mounted filesystem? Perhaps using the nfs automounter? If so then say so. Don't say "share" which implies a MS Windows SMB / CIFS network mount. The NFS client subsystem is notoriously bad. The nfs automounter is worse. I am guessing you probably really mean that you are using an nfs mounted filesystem using the automounter. Pretty much everyone in that situation has tried to recover from problems with it at one time or another. > The set -x output shows that the 'touch' command failed, but it > doesn't show why. That sounds like a bug in touch. If there is an error then it should emit an error message. Perhaps you should try an alternate command to create the file. You could use bash itself. : >> "$1"/.accesstest Or you could use a helper command. Using a different program other than 'touch' may cause it to emit a better error message. Bob
