Amanda-Users

Re: Volumes Failing: badly formatted response

2003-01-25 18:24:14
Subject: Re: Volumes Failing: badly formatted response
From: "John R. Jackson" <jrj AT purdue DOT edu>
To: John Arthur Kane <jkane AT pobox DOT com>
Date: Sat, 25 Jan 2003 16:57:30 -0500
>Due to the size of some of my volume mount points, I have 56 volume
>entries in my disk list for this server (out of 183 total).  ...

I assume you meant 56 entries for this *client*?

>I am having amdump fail with the message:
>
>    client /d4 lev 0 FAILED [badly formatted response from client]
>
>Where is the best place to figure out what is going on? Known bug?

As I recall, 2.4.1 still used a datagram size of 8 KBytes (unless you
tweaked the source).  2.4.1p1 bumped that to 64 KBytes.  If you're really
running 2.4.1 instead of 2.4.1p1 (that should be in the amandad*debug
file as well), that might explain it.

At 2.4.3 the server breaks requests into pieces to keep the responses
below MAX_DGRAM (64 KBytes) by assuming the response will be, at most,
twice the size of the request.  It's possible your client is generating
more response than expected and the server needs to be a bit more
aggressive.

Look in /tmp/amanda/amandad*debug on the client.  It will report the
both the request and response packet.  Copy the file to two temp files.
In one, look for text that starts like this:

  --------
  Amanda 2.4 REQ HANDLE 00A-20255978 SEQ 1042689912
  SECURITY USER backup
  ...
  --------

Note the "REQ".  That says this is the *req*uest packet.

Delete everything up to and including the first "--------" line, then
delete the second "--------" line and everything after it.

In the other file do the same thing but for the reply, which starts
out like this:

  ----
  Amanda 2.4 REP HANDLE 00A-2025E998 SEQ 1042690081
  OPTIONS maxdumps=1;
  / 0 SIZE 609481
  ...

Note the "REP".  That says this is the *rep*ly packet.

Then do an "ls -l" of both files and see how big the packets were.

You might also look at the reply and see if it looks reasonable.
My guess is it will look fine at the front and at the very end things
will be truncated, but it could also be some other silliness going on.

John R. Jackson, Technical Software Specialist, jrj AT purdue DOT edu

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