RE: amdump waits forever for estimates from one host
2005-06-12 00:40:04
The result:
-bash-3.00$ /usr/sbin/amadmin Daily tape
The next Amanda run should go onto a new tape.
The next Amanda run should go onto a new tape.
The next 2 new tapes already labelled are: Daily029, Daily028.
-bash-3.00$ /usr/sbin/amflush -f Daily
Scanning /var/tmp/amanda...
Could not find any Amanda directories to flush.
-bash-3.00$
-----Original Message-----
From: owner-amanda-users AT amanda DOT org
To: 'amanda-users AT amanda DOT org'
Sent: 6/11/2005 11:50 PM
Subject: RE: amdump waits forever for estimates from one host
It was a firewall problem, though it's a little odd that one client had
no
problem and another did, since the firewall was on the backup server.
With
the firewall
disabled (I'll attend to that later--the server and all the hosts are on
a
non-routable
"inside" network) there's a new problem: a tape error. So I guess I
have to
do
amadmin Daily tape
amflush -f Daily
These are the errors (slightly edited
Subject: CUNY Graduate Center AMANDA MAIL REPORT FOR June 11, 2005
*** A TAPE ERROR OCCURRED: [new tape not found in rack].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next 2 tapes Amanda expects to used are: a new tape, a new tape.
The next 2 new tapes already labelled are: Daily029, Daily028.
FAILURE AND STRANGE DUMP SUMMARY:
neptune-gw hda1 lev 0 FAILED [can't switch to incremental dump]
m254.gc.cu sda1 lev 0 FAILED [can't switch to incremental dump]
neptune-gw hda7 lev 0 FAILED [can't switch to incremental dump]
neptune-gw hda6 lev 0 FAILED [can't switch to incremental dump]
m254.gc.cu sda5 lev 0 FAILED [can't switch to incremental dump]
neptune-gw hda5 lev 0 FAILED [can't switch to incremental dump]
...
STATISTICS:
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 0:03
Run Time (hrs:min) 0:07
Dump Time (hrs:min) 0:00 0:00 0:00
Output Size (meg) 0.0 0.0 0.0
Original Size (meg) 0.0 0.0 0.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped 0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min) 0:00 0:00 0:00
Tape Size (meg) 0.0 0.0 0.0
Tape Used (%) 0.0 0.0 0.0
Filesystems Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
^L
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
KB/s
-------------------------- ---------------------------------
------------
m254.gc.cuny sda2 0 FAILED
---------------------------------------
m254.gc.cuny sda3 0 FAILED
---------------------------------------
....
neptune-gw.g hda6 0 FAILED
---------------------------------------
everything in disklist 0 FAILED
---------------------------------------
(brought to you by Amanda version 2.4.4p3)
-----Original Message-----
From: Frank Smith
To: Lengyel, Florian; ''amanda-users AT amanda DOT org' '
Sent: 6/11/2005 11:21 PM
Subject: RE: amdump waits forever for estimates from one host
--On Saturday, June 11, 2005 23:03:22 -0400 "Lengyel, Florian"
<FLengyel AT gc.cuny DOT edu> wrote:
> This is what I have in
m254:/tmp/amanda/amandad.20050611172037000.debug
>
> ...
> /home/m254/yfsong/ 0 SIZE 91630
> /home/m254/yzhu/ 0 SIZE 10
> ----
>
> amandad: time 260.577: dgram_recv: timeout after 10 seconds
> amandad: time 260.577: waiting for ack: timeout, retrying
> amandad: time 270.577: dgram_recv: timeout after 10 seconds
> amandad: time 270.577: waiting for ack: timeout, retrying
> amandad: time 280.577: dgram_recv: timeout after 10 seconds
> amandad: time 280.577: waiting for ack: timeout, retrying
> amandad: time 290.577: dgram_recv: timeout after 10 seconds
> amandad: time 290.577: waiting for ack: timeout, retrying
> amandad: time 300.577: dgram_recv: timeout after 10 seconds
> amandad: time 300.577: waiting for ack: timeout, giving up!
> amandad: time 300.577: pid 15364 finish time Sat Jun 11 17:25:37 2005
> [root@m254 amanda]#
>
> I previously set
>
> etimeout 400
>
> up slightly from the original 300 seconds.
>
> So it looks like a UDP packet never made it...Oh woe.
Looks like a firewall problem. Do you have one on either machine
and/or one in between them?
Frank
>
> -----Original Message-----
> From: Frank Smith
> To: Lengyel, Florian; 'amanda-users AT amanda DOT org'
> Sent: 6/11/2005 10:35 PM
> Subject: Re: amdump waits forever for estimates from one host
>
> --On Saturday, June 11, 2005 17:45:17 -0400 "Lengyel, Florian"
> <FLengyel AT gc.cuny DOT edu> wrote:
>
>> Amanda version: amanda-2.4.4p3-1
>> OS: CentOS
>> Kernel: uname -a
>> Linux amanda.grid.cuny.edu 2.6.9-5.0.3.ELsmp #1 SMP Sat Feb 19
> 19:38:02 CST
>> 2005 i686 i686 i386 GNU/Linux
>>
>> Trouble: amanda is set up on a tape server; there are two clients so
> far.
>> One is running RH linux 7.3 but has the latest (2.4.4) amanda code
> built
>> from
>> source...the other is using an older rpm under RH linux 9. The source
> build
>> machine
>> gives estimates for its DLEs, and the other seems to want to wait
> until
>> grass to grows
>> under its mounting bracket, according to amstatus Daily, part of
which
>> reads:
>>
>> m254.gc.cuny.edu:/home/m254/yzhu/ getting
> estimate
>> m254.gc.cuny.edu:/home/www getting
> estimate
>> m254.gc.cuny.edu:sda1 getting
> estimate
>> m254.gc.cuny.edu:sda2 getting
> estimate
>> m254.gc.cuny.edu:sda3 getting
> estimate
>> m254.gc.cuny.edu:sda5 getting
> estimate
>> m254.gc.cuny.edu:sda7 getting
> estimate
>> neptune-gw.gc.cuny.edu:hda1 0 8390k estimate
done
>> neptune-gw.gc.cuny.edu:hda5 0 6361840k estimate
done
>> neptune-gw.gc.cuny.edu:hda6 0 1361030k estimate
done
>> neptune-gw.gc.cuny.edu:hda7 0 163620k estimate
done
>>
>> I'm checking through the documentation...amcheck succeeds. Have I
made
> one
>> of the usual configuration oversights?
>
> Try checking the debug files on m254.gc.cuny.edu (default is in
> /tmp/amanda)
> and see if there is more information there.
>
> One possibility is a firewall blocking the estimate response, since
the
> response usually occurs long after most firewall connection timeouts.
> Look for 'no response' errors in the client debg files.
>
> Just so your backups don't hang forever you might want to make sure
your
> etimout isn't set larger than necessary. Don't forget it is multiplied
> by
> the number of DLEs on the host, so a setting of 1 hour on your m254
host
> could result in a wait of up to 7 hours. You can use a negative number
> it will be the per host timeout instead of per DLE.
>
> Frank
>
>
> --
> Frank Smith
> fsmith AT hoovers DOT com
> Sr. Systems Administrator Voice:
> 512-374-4673
> Hoover's Online Fax:
> 512-374-4501
--
Frank Smith
fsmith AT hoovers DOT com
Sr. Systems Administrator Voice:
512-374-4673
Hoover's Online Fax:
512-374-4501
|
|
|