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