Bug 151852 - named doesn't determine correct number of CPUs when run in chroot
named doesn't determine correct number of CPUs when run in chroot
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-22 16:37 EST by Jason Vas Dias
Modified: 2013-04-30 19:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-30 06:01:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2005-03-22 16:37:51 EST
Description of problem:

Named assumes only 1 CPU and uses 1 worker thread on a multi-cpu
machine when run in a chroot environment .

This happens in all releases: FC4, FC3, RHEL-4, RHEL-3.

This is because the proc filesystem is not mounted on $ROOTDIR/proc
when named runs chroot in $ROOTDIR .

Version-Release number of selected component (if applicable):
ALL

How reproducible:
100%

Steps to Reproduce:
run named in chroot on multi-processor machine
  
Actual results:
only 1 thread is forked

Expected results:
N worker threads where N == number of CPUs reported by
  sysconf(_SC_NPROCESSORS_ONLN)

Additional info:
Comment 1 Jason Vas Dias 2005-03-22 16:39:13 EST
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+ .
Comment 2 Enrico Scholz 2005-07-13 16:08:53 EDT
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?
Comment 3 Enrico Scholz 2005-07-13 16:29:28 EDT
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.
Comment 4 Jason Vas Dias 2005-07-13 16:51:50 EDT
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.
Comment 5 Warren Togami 2005-07-13 17:10:59 EDT
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
Comment 8 Jason Vas Dias 2005-07-19 12:54:13 EDT
This is now fixed with bind-9.3.1-8.FC5, bind-9.3.1-8.FC4, bind-9.2.5-3 (FC3).
 
Comment 9 Jonathan Hutchins 2005-07-24 11:42:20 EDT
I'm running 9.3.1.8.FC4 on a system with two dual core processors and showing 
only one  thread.   
Comment 10 Jason Vas Dias 2005-07-24 14:52:06 EDT
(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?
Comment 11 Adam Tkac 2007-05-30 06:01:25 EDT
Looks like fixed. If still exists, please reopen.

Regards, Adam

Note You need to log in before you can comment on or make changes to this bug.