[RFC][PATCH] krb5 => libverto main loop

ghudson@MIT.EDU ghudson at MIT.EDU
Thu Sep 8 01:18:43 EDT 2011


I found two more issues with this patch, unfortunately only after it
was committed to the trunk and put through our nightly build system.
Both issues pertain to the KDC worker process feature.

1. The KDC sets up the main loop state (inside libev or whatever) at
the same time as it binds listener sockets.  Then it forks multiple
child processes, each of which execute the main loop.  This assumes
that event libraries are fork-safe, which is a very dangerous
assumption.  For instance, libev is not fork-safe unless you tell it
to be.  Otherwise, signal delivery becomes unreliable because signals
result in a write to a duplicated pipe, and the read can occur in a
different child from the one the signal was sent to.  There are
basically two options to address this:

* Make fork safety a verto reqtype.  Inventory the event libraries for
  which ones support fork safety, and make sure to ask for it when
  requested if the back end needs to be asked.

* Major additional surgery on net-server.c.  Listener sockets have to
  be created in one step and remembered in a list, and then the main
  loop needs to be set up independently after child processes are
  forked.

2. There is a race condition where the monitor process isn't ready to
handle termination signals when the workers report "starting...".
This is mostly an issue for the test suite (t_workers.py), not a
practical issue, but we do need the test suite to work.  If the major
surgery for (1) is done, we can set the internal signal handler before
forking, and then replace it with the event loop signal handler when
the child process sets up its event loop.



More information about the krbdev mailing list