HUP handling: a thought

[Alan DeKok]

Joe Maimon wrote:
> Proper support for HUP is in my view an elemental requirement of any 
> properly functioning UNIX daemon.

  What does that mean?  "Proper" means... what?  Please be specific.

> If you feel its to complex to do it safely within the running code, you 
> can do it like sendmail daemon does, which simply rexecs itself with its 
> launching arguments. Sendmail doesnt support HUP if it wasnt started 
> with a full path.

  Sendmail has two nice features, like Apache, Bind, and most Unix servers.

  1) There is no state.
  2) Any state that may exist is on disk.

  dhcpd has state, but a well written dhcp server puts all of it's state
into a DB.  All of the information about a lease *must* be put into a
DB, otherwise it doesn't make sense.

  RADIUS isn't like that.

  There *is* state in a RADIUS server.  There are packets in flight from
a NAS to a home server.  Re-execing on HUP is a complete and total
non-starter.  It means that every HUP will cause *all* current login
sessions to be dropped.  Add to that ongoing EAP sessions, and every HUP
could cause a 5-10s service outage.

  If that's acceptable, we'll just release 2.0 with documented service
outages.  I *really* don't like that, though.

  To answer my first question.  People HUP the server to:

  a) add/edit/delete a client/realm/home-server
  b) re-read the "users" file
  c) not much else.

  If we make the server support (a) without HUP, that will address a
large part of my concerns.

  Did I mention I don't like re-exec'ing the server?

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog