Paul Bijnens wrote:
On 2008-02-14 09:56, Theodotos Andreou wrote:
Since a month ago I have the following problem appearing:
When amdump is completed amreport takes long to complete. When it
finally finishes it won't send any mail. Running amreport manually
results in a mail with subject:
It takes so long because the dump file contains lots of
"strange" lines probably. "Strange" = not expected in the normal
output of tar: Amanda collects those messages, prepends a '?' to
it and displays them in the mailreport. Amanda then leaves it up
to you to decide if that is bad, or harmless.
Because there are so many lines, generating the report takes very
long. And probably when sending the mail, it is refused by the
mailserver because the message is too large.
If it happens to be a full dump with many files, then the mail
was too large; when it contains only an incremental dump, it is
not that large, and you get the report.
I always force a full backup
Org DailyJob AMANDA MAIL REPORT FOR BogusMonth 0, 0
and body:
*** THE DUMPS DID NOT FINISH PROPERLY!
even though amstatus reports that all is OK. I even verified that the
images are present with amrestore.
Yes, but are all the images intact, and do they contain all the
data that was on the disk? Some DLE at least flagged as "not
good enough". Or maybe the filesystem containing the amdump.XX log
file was full resulting in amreport not finding the normal log lines
indicating a good backup.
According to amstatus all DLEs have the status finish but I will try to
verify some of them if they are correct
It is also peculiar that the problem is intermittent, It happens most
of the time but not always. I was not able to figure out what
triggers it.
I am using amanda 2.5.0p2 on CentOS 5.
I tried to strace on the running amreport and I got some strange
results:
read(3, "Warning: Cannot fgetfilecon: No data available\n ? gtar:
./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/uriloader/nsDocLoader.h:
Warning: Cannot fgetfilecon: No data available\n ? gtar:
Is this maybe related to:
https://bugzilla.redhat.com/431879
Did you recently upgraded tar, which generates a warning for each
file where se_linux context is not defined?
This could be the problem. Yum logs show an upgraded tar on Jan 18 and
the problems started on Jan 31.
--
Best Regards
Theodotos Andreou
System Administrator
PrimeTel PLC, Cyprus
www.prime-tel.com
