Amanda-Users

Re: 2.6.6-rc2 and newer cause trouble with amanda

2004-06-13 16:49:52
Subject: Re: 2.6.6-rc2 and newer cause trouble with amanda
From: Andreas Sundstrom <sunkan AT zappa DOT cx>
To: amanda-users AT amanda DOT org
Date: Sun, 13 Jun 2004 22:47:25 +0200
Paul Bijnens wrote:
Andreas Sundstrom wrote:

I'm sending this now to the amanda-users list, I originally sent it to the linux-kernel ml but the only person who have answered my mail is Gene Heskett which also recommended me to try here.

I'm using amanda-2.4.4p2 but I have also tried 2.4.5b1-20040510 with the same results.

I have trouble upgrading from 2.6.5 to 2.6.6, I have narrowed it down
by trying the different rc releases. Between 2.6.6-rc1 and 2.6.6-rc2
something happens that make my amanda backups fail with the error
[bad CONNECT response].


Is this on the server or on the client or both?
both (I mean this is all happening on a local computer with tapedrive attached)




If I do nothing else than boot to 2.6.6-rc1 from rc2 it works so it seems to be somthing with the kernel that is causing the
trouble, but I don't know how to investigate further.

This is the best debug info I've found so far.


You only send sendbackup.  Does it mean that amcheck does not give
any errors?
Yes, amcheck says that everything is ok.




Non-working:
root@zappa:/var/tmp/amanda# cat sendbackup.20040511223325.debug
sendbackup: debug 1 pid 2463 ruid 0 euid 0: start at Tue May 11 22:33:25 2004
/usr/lib/amanda/sendbackup: version 2.4.4p2
  parsed request as: program `GNUTAR'
                     disk `/boot'
                     device `/boot'
                     level 1
                     since 2004:5:11:10:6:42
options `|;bsd-auth;index;exclude-list=.amanda.excludes;exclude-optional;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.564 sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.565 sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.566
sendbackup: time 0.008: waiting for connect on 564, then 565, then 566
sendbackup: time 30.003: stream_accept: timeout after 30 seconds
sendbackup: time 30.003: timeout on data port 564
sendbackup: time 59.998: stream_accept: timeout after 30 seconds
sendbackup: time 59.998: timeout on mesg port 565
sendbackup: time 89.994: stream_accept: timeout after 30 seconds
sendbackup: time 89.994: timeout on index port 566
sendbackup: time 89.994: pid 2463 finish time Tue May 11 22:34:55 2004


It seems that there is some networking issue.
Have you ruled out a misconfigured iptables?
Yes, I have flushed the rules and set default policy to ACCEPT everywhere.


Try with to see what happening on the wire with tcpdump.
This I haven't done, might be worth a shot. Don't have time to do this right now but as soon as I have done it I'll mail the results.


...


Any ideas of how to investigate further? It seems that I'm the only
one with this problem beacause I can't find any other posts about
this. Unfortunately I don't have any other computers with tapedrives
on them to try and reproduce the problem (although it seems to be
about networking so a tapedrive might not be necessary to investigate
further).


You don't need a tapedrive at all.  Read the FILE-HOWTO in the
docs directory to setup virtual tapes. Takes only 5-10 minutes.
Ok, then I might be able to reproduce on a faster machine that doesn't need to be running 24/7




Thanks for any help.

Let me know if I need to post more info, don't want to write an unnecessary overly large e-mail.


You may always mail me personally the complete debugging info, or
packet trace if you like.
I'll see if I can understand anything from the packet dump if not I might send them to you for a quick look.

Thanks for your time and keep coming with more good ideas ;)

/Andreas

<Prev in Thread] Current Thread [Next in Thread>