Re: exit status issue

[Greg Wooledge]

On Tue, Nov 22, 2011 at 02:55:28PM -0600, Dallas Clement wrote:
> fsaccesstest()
> {
>       set -x
> 
>       local RETRY_MAX=3
>       local RETRY_INTERVAL=3
>       local CHK_RESULT=1
>       local RETVAL=0
> 
>       TMP=`grep "$1" /proc/mounts|awk '{print $1}'`
>       if [ "$TMP" != "" ]; then
>               for i in `seq 1 ${RETRY_MAX}`
>               do
>                       touch "$1"/.accesstest
>                       CHK_RESULT=$?
>                       if [ ${CHK_RESULT} -eq 0 ] ; then
>                               break
>                       fi
>                       logger -s -t ${LOGTAG} -p ${LOGFACILITY} "*** 
> fsaccesstest test $1
> failed CHK_RESULT=$CHK_RESULT. retrying... (${i}) ***"
>                       sleep ${RETRY_INTERVAL}
>               done
>               if [ $CHK_RESULT -ne 0 ]; then
>                       RETVAL=$CHK_RESULT
>               fi
>       fi
> 
>       set +x
> 
>       return $RETVAL
> }

That does look better.

> + touch /mnt/array1/.accesstest
> + CHK_RESULT=1
> + '[' 1 -eq 0 ']'
> + logger -s -t diskmon -p local0.info '*** fsaccesstest test
> /mnt/array1 failed CHK_RESULT=1. retrying... (1) ***'
> diskmon: *** fsaccesstest test /mnt/array1 failed CHK_RESULT=1.
> retrying... (1) ***

> 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.

OK.

> The set -x output shows that the 'touch' command failed, but it
> doesn't show why.

Presumably the touch command itself will tell you why, on stderr.  It
should say something like "No such file or directory" or "Permission
denied" or "Device or resource busy", etc.

> The three system calls that touch makes are all successful.
> So my question is why is $? getting set to 1?

If you suspect a bug in touch, then you need to report it to your OS
vendor.  touch isn't part of bash.

> It looks to me like the
> bash interpreter is returning early from this call to 'touch'.  I
> can't prove this yet though.

There's no way bash would do that, given the script as shown.  There is
no background execution there at all.

> Here's another example of an unsuccessful touch execution.  Notice how
> the execution keeps getting interrupted and then resumed.

This is getting into kernel scheduling, etc.  Way off topic for a bash
mailing list.  You might need to take this up on the Linux Kernel
Mailing List, or something similar if you are not doing this in Linux.