Not sure I understand, this really doesnt effect
what the problem actually is with the server not
responding after 10-12 hours to several days (when I
was on vacation) waiting for a down client that will
not send an estimate. Even after changing to different
timeout
Sorry, no mal intent just not sure I get the reasoning.
Thanks.
On Fri, 15 Apr 2011, gene heskett wrote:
On Friday, April 15, 2011 12:39:19 PM Tim Johnson did opine:
I have already tried changing the etimeout, as stated before the
timeouts are :
etimeout 8000 (changed from 5000 and the origanal -600)
( the long wait is due to a few of the machines being very old 800 MHz)
dtimeout 2800
ctimeout 60
I believe I tried using a -5000 seconds and see if it worked
before, however I will try it now and see what happens.
On Fri, 15 Apr 2011, gene heskett wrote:
On Friday, April 15, 2011 10:17:50 AM Tim Johnson did opine:
Just a follow up on this issue, which isnt makeing
sense to me at all.
I shut down the amanda client via xinetd, and ran
the backups and the backups worked perfectly. It went over
the client with the report mentioning that the client
was not responsive.
However, I had someone (by accident?) turn off the power
to one of the amanda clients. This caused the backup on the
server to continue to wait for the estimate of the client
for hours (over 10 hours).
I have tried using calcsize, client, and no entry for
the estimate (I dont know what the default is, calcsize (?) ).
No error messages in the logs, just the hanging server waiting
for the estimate of the non responsive client.
I will be trying different options to see what occurs.
Thanks for any input.
That is controlled by the 'etimeout' value in your amanda.conf, and
its stated in seconds. IIRC I'm set at 800 seconds but that is
overkill by at least a factor of 2. That is about 13 minutes in
round figures. Depending on one drive speeds and iron in the cpu, 300
(5 minutes) is probably adequate for most smaller uses.
[...]
At 8000, that would be 2:22 hours, per missing DLE, although if on
different 'spindles' this can be done in parallel by amanda. I would not
set it at more than 200% of the longest etime consumed during a normal, all
DLE's present backup.
I believe each physical drive in the system should have its own unique
'spindle' number in the disklist in order for this to work as intended. It
can make a noticeable diff in overall backup time even if there are only 2
'spindle's being backed up. I am guessing that having >10 would probably
need a gigabyte network to stay within the available bandwidth though.
However, if you are approaching that scenario, it would be a good selling
point to TPTB that you need a network upgrade if yours is only 100 megabaud
now.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
There are twenty-five people left in the world, and twenty-seven of
them are hamburgers.
-- Ed Sanders
