kadmin incremental propagation full resync multiple processes spawned

[Tom Yu]

"Paul B. Henson" <henson at acm.org> writes:

> As I understand it, the issue is that there is no "get a lock, wait in
> line if it's not available" call.

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,
but we can probably make it work because currently none of the
processes involved are multithreaded.  (I'd have to check whether the
recent libverto integration will add complications for kadmind,
though.)

> The current approach tries five times with a 1
> second delay in between tries to get the lock, then gives up. If
> somebody else (in this case kadmind) is also busily grabbing the lock,
> and sitting on it, the odds of you getting in to get it aren't
> necessarily that good.

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.