bind9 doesn't close extra fds

James Ralston qralston+ml.bind-workers at andrew.cmu.edu
Wed Sep 4 04:15:04 UTC 2002


On Tue, 27 Aug 2002, Paul Vixie wrote:

> > > bind8 loops for over a minute on modern hardware for which
> > > _SC_OPEN_MAX is often 16777216.
> > 
> > That *is* quite large...
> 
> it sure surprised the heck out of *us*.
> 
> > > the bind9 behaviour was minimalistic.
> > 
> > But is it right?  In my experience, programs are expected to close
> > unnecessary file descriptors when they daemonize.  Perhaps this
> > behavior could be made conditional for the "modern hardware" you
> > mentioned.
> 
> we could keep closing until fd>_SC_OPEN_MAX or the number of failed
> closes due to EBADF exceeded some threshold (42 being my favourite.)

This seems like a kluge.  If we agree with W. Richard Stevens
et. al. that daemons should close all unneeded file descriptors, then
BIND should do it Right instead of doing what seems to be Good Enough.

How about making the default behavior for BIND to close all fds up to
_SC_OPEN_MAX, but provide the user with the equivalent of a
"DontBlameSendmail" flag.  E.g.:

       -q     Launch the daemon in "quick" startup mode.  Normally,
              after named launches into the background, it thoroughly
              sanitizes its calling environment, which can take
              several seconds to several minutes on certain systems.
              Supplying the -q flag will cause named to perform an
              abbreviated startup sequence.

              WARNING: this option may compromise security, and SHOULD
              NOT BE USED.  Only use it if BIND takes an intolerably
              long time to startup on your system.  (And even if you
              have such a system, think long and hard before you use
              this option.)

Thoughts?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



More information about the bind-workers mailing list