It might be best to avoid quoting large portions of the existing 
thread when replying to krb5-bugs messages; it harder to read the web 
display of the ticket.

I took a look at the relevant code today.  My findings are:

* clnt_tcp.c always calls select() with a non-null timeout parameter.  
So it would be easier to raise the timeout value to a large number 
than it would be to eliminate the timeout entirely.

* The currently operative timeout comes from the "TIMEOUT" variable 
(not a macro, despite the all-caps name) in 
lib/kadm5/clnt/client_rpc.c.

* This value could be overridden by calling clnt_control() with 
CLSET_TIMEOUT on the client handle in client_init.c.

* As a side note, the generic clnt_create() calls clnt_control() with 
CLSET_TIMEOUT on the resulting handle, which is mystifying since it 
defeats the purpose of remembering whether the caller wanted to 
override the default timeout or not.  Other RPC implementations 
(libtirpc, OpenSolaris) don't appear to do this.  This doesn't really 
matter since we don't use clnt_create() in kadmin; we call 
clnttcp_create() directly.

* The hardcoded timeout used to be 25 seconds.  We changed it to 120 
seconds (in both client_rpc.c and clnt_generic.c) in release 1.7.

My plan is:

* In one commit, add a call to clnt_control() in client_init.c 
changing the timeout to 3600 seconds.

* In a second commit, revert the TMIEOUT variable in client_rpc.c to 
25 (to match what rpcgen originally regenerated) and remove the calls 
to clnt_control() in clnt_generic.c.  This won't have any significant 
practical effect and is just for hygiene.