amandad: #define REP_TIMEOUT (6*60*60)

Hi,

I've been noticing backup failures where amstatus reports
failed: planner: [disk ..., all estimate timed out]

and in the amandad debug log:

amandad: ...sendsize timed out waiting for REP data
amandad: sending NAK pkt:
<<<<<
ERROR timeout on reply pipe

This timeout seems to be hardcoded in amandad.c:
https://github.com/zmanda/amanda/blob/master/amandad-src/amandad.c#L50

#define	REP_TIMEOUT	(6*60*60) /* secs for service to reply */

and indeed, the timestamp in the debug log where the timeout is
reported is exactly six hours after the timestamp when the sendsize
process was started.

Now, this client gets sent about 60 DLEs in one request for estimates.
And during those six hours, it was steadily sending estimate replies,
one DLE at a time, every several minutes to a half hour or so.
In fact, at the time it was killed by this timeout, it had just sent
the latest reply only 11 minutes before.

I wonder if it would make more sense to use a shorter timeout
for this purpose, but one that gets extended every time a reply
is received, so it would really only time out if replies actually
stopped arriving. I think there would still be the (configurable!)
etimeout from amanda.conf enforced on the server end.

Does that seem reasonable?

Meanwhile, is there an easy way to work around this problem?
If I were to edit these 60 DLEs and give them spindle numbers
(right now they are all -1), would that cause the planner to
put them into multiple estimate requests so that no request
would have two DLEs with the same spindle number?

Thanks,
-Chap