kadmin incremental propagation full resync multiple processes spawned

[Paul B. Henson]

On 11/4/2011 4:10 PM, Tom Yu wrote:

> What I was alluding to was operations like the F_SETLKW (as opposed to
> F_SETLK) command of POSIX fcntl(), which will block on acquiring the
> lock.  It has a drawback of lacking timeout capability, so callers
> would have to arrange for a timeout by using alarm() or something.
> This isn't really viable in a multithreaded process, or in a library

Ah, ok, forgot about blocking fcntl :), it's been a while since I've 
worked with file locking code. Yah, I've run into issues in the past 
where I've had an alarm set and something else stomped over it :(. 
Theoretically I suppose you could try to save the existing SIGALRM 
handler and remaining time on the current alarm, but that doesn't seem 
very reliable and rather messy.

Also, the success of a blocking lock implementation would depend on 
whether or not the underlying OS implemented fair lock scheduling. I 
think Solaris does, but I don't know that Linux (our current OS for 
kerberos servers) does.

> The kprop process is probably also fighting with the main KDC process
> in acquiring the lock, so if you have a heavy authentication load
> going on at the same time, the problem could get worse.

The batch jobs run at 3:30am, so not too much authentication load :).


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768