KDC worker processes project

ghudson@MIT.EDU ghudson at MIT.EDU
Thu Sep 16 15:44:39 EDT 2010


I'm beginning a formal review of the KDC worker processes project,
ending next Friday.  The project proposal is at:

http://k5wiki.kerberos.org/wiki/Projects/Parallel_KDC

The purpose of this project is to allow better KDC scalability on
multi-processor KDC hosts, or KDC hosts making use of slow database
modules.  Possibly controversial aspects of the proposal are:

* The supervisor is very simplistic.  It only knows how to propagate
  HUP signals to children (all we do on a HUP right now is re-open the
  KDC logfile), and how to terminate worker processes if the
  supervisor receives a termination signal or any worker process
  exits.

  (Why terminate all workers when one exits, instead of restarting the
  worker?  So that the KDC has similar behavior on a crash with or
  without worker processes.  The goal of this feature is to provide
  scalability, not to increase KDC uptime in the face of bugs.)

* If you use worker processes, you don't get network reconfigs.  If
  your platform supports IPv4 pktinfo (Linux or modern Solaris), this
  is not a change in behavior.  If your platform does not support
  pktinfo, then the KDC will have to be restarted in order to
  recognize newly added network interfaces.

* KDB modules will be closed in the supervisor just before forking and
  then opened in each child by reinvoking initialize_realms(), which
  will re-parse the argument list.  I don't think it's a terribly
  clean design that we combine argument parsing and realm
  initialization, but we have such a tangle of realm options that it's
  not trivial to separate them out.

* There won't be automated tests; it's just too hard.  There will be
  manual tests which will involve some temporary code modifications.

Because we only added this to the 1.9 slate a few months ago when
things had already gotten busy, implementation time is very limited.
So while it's fair to advocate for a more complicated design, also
consider whether the current design is better or worse than the status
quo.



More information about the krbdev mailing list