Re: [Savannah-hackers] pserver broken

[Joel N. Weber II]

Hmm, some random reactions:

1) I think I would have rebooted in that situation, too.

2) If you find out how to avoid rebooting, I'd be interested, too.

3) xinetd seems to be annoyingly flakey, in a way that inetd doesn't
   seem to be.  We seem to have seen this on both fencepost and
   subversions.  I don't think we want to continue to use an xinetd
   with the current bugginess for forever.

   I can offer several possibilities of what we could do about it:

   a) Check the debian bug tracking system, and possibly an upstream
      bug tracking system.  Perhaps such a thing will contain some clues
      about how to fix the problem.  loic, if you want to look into
      this problem furthur, that's probably a good first step.

   b) Spend time debugging xinetd ourselves.  Nice theory, but given
      our current rsync track record, I don't think it's going to
      happen.  (It would be really cool if someone could make me look
      like a pessimist here, though.)

   c) See if we have any alternatives to xinetd or the traditional
      inetd.

   d) If none of the above seem sufficient, I think I would feel
      comfortable looking at modifying the standard inetd in some way
      so that you can restrict which IP it listens on.  The most
      trivial way to do that would probably be to add a command line
      option which specifies the one IP address this inetd listens on,
      and then you run several inetds, each one being told the IP
      address to listen on and the config file to read.  The total
      time it would take me to do this, ignoring the savannah scripts,
      is probably 1-4 hours, and I can probably find time to do this
      in the next month or so if we don't find any better alternatives
      and people think this is a good idea.

Note that options c) and d) would probably end up requiring modifying
scripts that savannah uses to update the config files.