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

[Nathaniel McCallum]

Attached is a series of patches to deal with these issues. They will require verto from git (where I added verto_reinitialize() and the VERTO_EV_FLAG_REINITIABLE flag). Basically this makes verto handle the fork well. Only the UDP, TCP Listener and RPC Lisener sockets are carried through the fork. Lastly, if the server is going to spawn worker processes, the setup of signal handlers is delayed until post-fork. We then are able to move the forwarder signal handlers to exist before the fork. I believe that this should solve all the issues listed below.

Nathaniel

----- Original Message -----
From: ghudson at MIT.EDU
To: krbdev at MIT.EDU
Sent: Thursday, September 8, 2011 1:18:43 AM
Subject: Re: [RFC][PATCH] krb5 => libverto main loop

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-reinitialize-verto-after-the-fork-make-the-proper-so.patch
Type: text/x-patch
Size: 2265 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110909/4711dc4f/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-split-out-signal-event-setup-from-loop_init-into-loo.patch
Type: text/x-patch
Size: 6202 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110909/4711dc4f/attachment-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-move-the-child-signal-handlers-to-before-the-fork-to.patch
Type: text/x-patch
Size: 2630 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110909/4711dc4f/attachment-0002.bin