Fixed by mounting proc on $ROOTDIR/proc if not already mounted in 
startup script, in bind-9.2.5-2+, bind-9.3.1-2+ .

Is it really a clever idea to mount /proc in the chroot(2) area? Why are the
number of CPUs not calculated by the initscript (before the chroot(2)) and given
to named with the '-n #cpus' switch?

sample code might be:

| [ -r /etc/sysconfig/named ] && . /etc/sysconfig/named
| ...
| : ${BIND_NPROCESSORS=$(getconf _NPROCESSORS_ONLN)}
| ...
| start() {
|    ...
|    daemon ... ${BIND_NPROCESSORS:+-n $BIND_NPROCESSORS}


'BIND_NPROCESSORS' can overridden by /etc/sysconfig/named in this way.

The issue is not only the number of CPUs sysconf, but use of other sysconfs
or sysctls in the code, and of the /proc filesystem by glibc networking calls. 

Also users may already have specified -n in the existing 
/etc/sysconfig/named $OPTIONS variable.

I think it is safer longterm to ensure that code tested with /proc mounted 
is run under a chroot which also has /proc mounted.

The only issue to have arisen so far during several months of testing in 
rawhide & FC4 is that the 'df' command will return an error for non-root
users if /proc is mounted under /var/named/chroot - to workaround, 
'chmod a+rx /var/named/chroot' - nothing secure is stored in the top level
chroot directory anyway.

Use of the chroot is deprecated in favor of using SELinux in enforcing mode.
The SELinux named policy provides far greater security than that of a chroot
environment, and makes use of a chroot for named redundant.

Jason, could you please use something like the below in order it allow mount to
silently fail?  Some chroot environments have kernel cap mount restricted for
security reasons, so this is problematic.

--- named       2005-05-17 16:42:02.000000000 -1000
+++ /tmp/named  2005-07-13 10:20:37.000000000 -1000
@@ -46,7 +46,8 @@
                    mkdir -p ${ROOTDIR}/proc
                fi
                if ! egrep -q "${ROOTDIR}/proc proc" /etc/mtab; then
-                   mount -tproc none ${ROOTDIR}/proc
+                   # Allow it to fail quietly since cap mount is restricted in
some environments
+                   mount -tproc none ${ROOTDIR}/proc > /dev/null 2> /dev/null
|| /bin/true
                fi
        fi
        no_write_master_zones=0

This is now fixed with bind-9.3.1-8.FC5, bind-9.3.1-8.FC4, bind-9.2.5-3 (FC3).
 

I'm running 9.3.1.8.FC4 on a system with two dual core processors and showing 
only one  thread.   

(In reply to comment #9)
> I'm running 9.3.1.8.FC4 on a system with two dual core processors and showing 
> only one  thread.   

Are you sure named is using only one "worker thread" ? With use of the new NPTL
threads library now the default, threads no longer appear as separate processes
in a 'ps' listing, as they did before. What is the output of the command:
   # grep 'named.*worker thread' /var/log/messages 
It should be:
   named[XXXX]: found 2 CPUs, using 2 worker threads
And the output of
   # ls -l /proc/XXXX/task | egrep -v '^total' | wc -l
should be 5, not 4 .

If named reports only 1  'worker thread', and you have only 4 named tasks:

Are you running an smp kernel ?

Are you running named in a chroot (do you have the bind-chroot package 
installed)? 

If so, is the /proc filesystem mounted under /var/named/chroot/proc ? 

named uses the same sysconf( _SC_NPROCESSORS_ONLN ) call that is accessed by
the command:
 # getconf _NPROCESSORS_ONLN
What is the output of this command on your system?

What is the output of the command
 # . /etc/sysconfig/named; cat $ROOTDIR/proc/stat
This should show multiple CPUs .

Note: use of the '-n X' option to named overrides CPU detection with an 
explicit 'number of CPUs' value - do you have a '-n' setting in the
/etc/sysconfig/named "$OPTIONS" variable?

Looks like fixed. If still exists, please reopen.

Regards, Adam