Hi

Have you had a look at your amanda tape server amanda.conf file
and amending the etimeout parameter default is usually 300 seconds.

I run less command on /tmp/amanda/amanda-date-.debug and my client was
timing out on 180.33 seconds So I had read a good possibility is that
udp which is stateless is taken to my time and hences times out.

Worth a try I hope it helps I have a similar problem amcheck states no
errors found but whem amdump tries to do it's thing I get a timeout
error as below:

amandad: time 180.183: dgram_recv in
debug report.


So I am googggling around and reading amanda mailing list for a solution
to my issue I am nearly there.

All the best.

On Tue, 2006-02-21 at 09:45 +0100, Stefan Herrmann wrote:
> hello list,
> 
> i made a fresh install of "Amanda 2.5.0b2" on a debian 3.1 system. then 
> i set up amanda for a hourly backup.
> i did some test backups that worked ok. then i mentioned an error in 
> the amanda.conf and aborted the dump
> manually. stopped all amanda processes on the client manually and 
> corrected the error. since then i get lots of
> "(aborted:[request failed: timeout waiting for ACK])(too many dumper 
> retry)" when doing backups:
> 
> amanda@amanda:~$ amstatus hourly
> Using /usr/local/etc/amanda/hourly/amdump.1 from Tue Feb 21 09:22:36 
> CET 2006
> 
> pille.hq.imos.net:/    0 driver: (aborted:[request failed: timeout 
> waiting for ACK])(too many dumper retry)
> pille.hq.imos.net:/opt 0 driver: (aborted:[request failed: timeout 
> waiting for ACK])(too many dumper retry)
> pille.hq.imos.net:/usr 0 driver: (aborted:[request failed: timeout 
> waiting for ACK])(too many dumper retry)
> pille.hq.imos.net:/var 1       45m finished (9:28:16)
> 
> SUMMARY          part      real  estimated
>                             size       size
> partition       :   4
> estimated       :   4                55036m
> flush           :   0         0m
> failed          :   3                55015m           ( 99.96%)
> wait for dumping:   0                    0m           (  0.00%)
> dumping to tape :   0                    0m           (  0.00%)
> dumping         :   0         0m         0m (  0.00%) (  0.00%)
> dumped          :   1        45m        20m (220.31%) (  0.08%)
> wait for writing:   0         0m         0m (  0.00%) (  0.00%)
> wait to flush   :   0         0m         0m (100.00%) (  0.00%)
> writing to tape :   0         0m         0m (  0.00%) (  0.00%)
> failed to tape  :   0         0m         0m (  0.00%) (  0.00%)
> taped           :   1        45m        20m (220.31%) (  0.08%)
>    tape 1        :   1        45m        20m (  0.04%) hourly009
> 6 dumpers idle  : no-dumpers
> taper idle
> network free kps:     14000
> holding space   :    258607m (100.00%)
> chunker0 busy   :  0:00:00  (  0.00%)
>   dumper0 busy   :  0:03:10  ( 36.36%)
>     taper busy   :  0:00:02  (  0.55%)
>   0 dumpers busy :  0:08:37  ( 98.82%)            not-idle:  0:05:31  ( 
> 64.11%)
>                                         client-constrained:  0:02:01  ( 
> 23.49%)
>                                                 start-wait:  0:00:34  (  
> 6.57%)
>                                                 no-dumpers:  0:00:30  (  
> 5.83%)
>   1 dumper busy  :  0:00:05  (  1.05%)          start-wait:  0:00:05  ( 
> 99.46%)
> 
> i already rebooted the amanda server and cant find any more processes 
> running on the client. also did a restart of
> inetd on the client.
> 
> does anyone have a clue whats the problem ? os what this abort message 
> means ?
> 
> thanks and by
> Stefan Herrmann
> 
> 
-- 
Unix/ Linux Systems Administrator
Chuck Amadi
The Surgical Material Testing Laboratory (SMTL), 
Princess of Wales Hospital 
Coity Road 
Bridgend, 
United Kingdom, CF31 1RQ.
Email chuck.smtl.co.uk
Tel: +44 1656 752820 
Fax: +44 1656 752830