bind9 doesn't close extra fds
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
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
More information about the bind-workers