On Fri, Mar 26, 2010 at 10:32 AM, Gene Heskett <[email protected]> wrote:
> In bash, you can assign that error and process accordingly.  Here is a
> snippet of that part of my wrapper script, with the language sanitized
> for the list:
>
>       ${AM_SBIN_DIR}/amdump $CONFIGNAME $HOST $DLE >> $LOG
>        SCS=$?
>        echo ${AM_SBIN_DIR}"/amdump "$CONFIGNAME $HOST $DLE" returned "$SCS 
> >>$LOG
>        if [[ $SCS -ne "0" ]] ; then
> # according to the info page, any error is "probably a 2" return.  Dumb, 
> effing dumb.  Real effing dumb even.
> # so apparently a file that got changed in the users maildir is an error.  
> Its gonna happen, just ignore it.
>                if [[ $SCS -gt "2" ]] ; then
>                        echo "amdump THINKS it or tar failed for some reason, 
> see the $LOG file." |tee -a $LOG
>                fi
>
> The $? transfers the return value to the SCS variable. $SCS is then checked
> to see if its a real error.

Amdump's exit statuses are here, by the way:
  http://wiki.zmanda.com/man/amdump.8.html

We've kept the strange messages as a distinct error because they *can*
represent data loss.  For example, if your accounts_receivable.db is
marked as STRANGE in every backup since the dawn of time, then you
don't actually have a backup of your accounts receivable!  In general,
the right way to make spurious "file changed as we read it" errors go
away is exclude lists.

Michael, Amanda-3.1 has a much simpler implementation of amreport, so
it wouldn't be too difficult to hack it to ignore STRANGE messages.
I'm not sure I'd want to merge such a hack, but I'm open to
persuasion!

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com

Reply via email to