Jean-Francois Malouin wrote:

* Garnet Harris <garnet.harris AT ekasystems DOT com> [20091030 13:33]:

client sendsize log:

sendsize[8661]: time 9899.506: estimate time for home_q level 0: 12.033
sendsize[8668]: time 13962.655: estimate time for home_r level 0: 4063.141
sendsize[9335]: time 30708.356: estimate time for home_s level 0: 16745.578


server planner log:

time 9899.665: dgram_recv(dgram=0xb805c764, timeout=0, fromaddr=0xb806c750)

time 9899.665: (sockaddr_in6 *)0xb806c750 = { 10, 10080, ::ffff:192.168.0.247 }

time 13962.833: dgram_recv(dgram=0xb805c764, timeout=0, fromaddr=0xb806c750)

time 13962.833: (sockaddr_in6 *)0xb806c750 = { 10, 10080, ::ffff:192.168.0.247 }

time 21600.190: dgram_recv(dgram=0xb805c764, timeout=0, fromaddr=0xb806c750)

time 21600.211: (sockaddr_in6 *)0xb806c750 = { 10, 10080, ::ffff:192.168.0.247 } time 40082.633: security_seterror(handle=0x80721f8, driver=0xb804a720 (BSD) error=timeout waiting for REP)

time 40082.665: security_close(handle=0x80721f8, driver=0xb804a720 (BSD))
time 40082.719: pid 6922 finish time Sun Oct 25 19:08:03 2009

Something is happening at 21600 (6 hours). The server recevies a dmesg from somewhere (there is no corresponding entry in the sendsize log) and stops looking for estimates from the client. Then waits another 5 hours before it starts the actual backup.

Any idea what is happening at 21600?

Thanks for the reply.

Look at REP_TIMEOUT = (6*60*60) set in amandad-src/amandad.c, ie 6hrs.

You either have to figure out why your
clients are so slow or recompile the client with a bigger REP_TIMEOUT.

--
Garnet Harris                           TEL: +301 515 7118
Eka Systems                             FAX: +301 515 4965
20201 Century Blvd., Suite 250
Germantown, MD   20874                  garnet.harris AT ekasystems DOT com