On Wed, Jan 20, 2021 at 14:22:02 +1100, Tom Robinson wrote:
> I'm still seeing messages in the report that should have been squashed. It
> also doesn't matter what I have configured as 'NORMAL' for the application
> configuration.
> 
> STRANGE DUMP DETAILS:
>   /-- lambo.motec.com.au / lev 1 STRANGE
>   sendbackup: info BACKUP=APPLICATION
>   sendbackup: info APPLICATION=amgtar
>   sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc
> |/usr/lib64/amanda/application/amgtar restore [./file-to-restore]+
>   sendbackup: info COMPRESS_SUFFIX=.gz
>   sendbackup: info end
>   | /usr/bin/tar: ./dev: directory is on a different filesystem; not dumped
>   | /usr/bin/tar: ./proc: directory is on a different filesystem; not dumped
>   | /usr/bin/tar: ./run: directory is on a different filesystem; not dumped
>   | /usr/bin/tar: ./sys: directory is on a different filesystem; not dumped
>   | /usr/bin/tar: ./mnt/s3backup: directory is on a different filesystem; not 
> dumped
>   | /usr/bin/tar: ./var/lib/nfs/rpc_pipefs: directory is on a different 
> filesystem; not dumped
>   ? /usr/bin/tar: ./mnt/s3backup: Warning: Cannot flistxattr: Operation not 
> supported

[...]
>     property        "NORMAL" ": socket ignored$"
>     property append "NORMAL" ": file changed as we read it$"
>     property append "NORMAL" ": directory is on a different filesystem;

Note that the man page explaination of NORMAL includes the sentence
'These output are in the "FAILED DUMP DETAILS" section of the email
report if the dump result is STRANGE'.

In this case, the "Operation not supported" message is considered
STRANGE... which in turn causes all the NORMAL message lines to be
included in the report output as well.

So presumably once you resolve all of those error messages for a
particular DLE, that DLE will no show up with a STRANGE DUMP DETAILS
section at all, in which case those NORMAL-category messages will no
longer be included in the report.

(You could prevent those messages from ever showing up in the report by
setting them to IGNORE in the config file, but in general I'd say trying
to fix the underlying cause of a STRANGE status is preferable to
suppressing messages completely....)


Does that explain the behavor you were seeing?


                                                Nathan


----------------------------------------------------------------------------
Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Reply via email to