Number of CPUs detected by Bind 9.4.2 on 4 CPU system running RedHat es 4.
greg kuechle
I have install bind 9.4.2 on a system with 4 CPUs running RedHat es4. I
compiled named with the --enable-threads and used the -n 4 flag when I
start named.
Mar 31 10:12:24 ******** named[4897]: starting BIND 9.4.2 -t /opt/named
-u named -n 4 -c /etc/named.conf
Mar 31 16:12:24 ******** named[4897]: found 1 CPU, using 4 worker threads
Before I upgraded the system it was running an older version of named that
comes packaged with the OS.
Here is the output from the logfile.
Mar 24 11:34:13 ******** named[5877]: starting BIND 9.2.4
Mar 24 11:34:13 ******** named[5877]: using 4 CPUs
Did I compile named wrong?
Will BIND 9.4.2 use all of the CPUs if I use the -n 4 option at startup?
It looks like named is only running on one CPU. Will named start using the
other CPUs once one CPU is up to 100% ?
Thank you for any help.
Regards,
Greg.
------------------------------------------------
Greg Kuechle, A.Sc.T.
Technical Analyst
SaskTel
-----------------------------------------------
Matus UHLAR - fantomas
> I have install bind 9.4.2 on a system with 4 CPUs running RedHat es4. I
> compiled named with the --enable-threads and used the -n 4 flag when I
> start named.
>
> Mar 31 10:12:24 ******** named[4897]: starting BIND 9.4.2 -t /opt/named
> -u named -n 4 -c /etc/named.conf
> Mar 31 16:12:24 ******** named[4897]: found 1 CPU, using 4 worker threads
does your kernel support more CPUs? Seems it does not. Maybe you should
re-compile or use another (SMP) kernel.
> Before I upgraded the system it was running an older version of named that
> comes packaged with the OS.
> Here is the output from the logfile.
> Mar 24 11:34:13 ******** named[5877]: starting BIND 9.2.4
> Mar 24 11:34:13 ******** named[5877]: using 4 CPUs
seems named found 4 CPUs here... you had SMP kernel before the upgrade.
> Did I compile named wrong?
the kernel, not the named, imho.
> Will BIND 9.4.2 use all of the CPUs if I use the -n 4 option at startup?
No, named will create 4 threads if you use "-n 4", independently on number
of CPUs in the system. Whether threads will be run on more CPU's, depends
completely on the kernel. On single-processor kernel everything will use
just one CPU.
If you don't use the "-n" switch, named will detect the number of processors
and decide itself, how much threads to start. That's recommended and default.
> It looks like named is only running on one CPU. Will named start using the
> other CPUs once one CPU is up to 100% ?
I doubt, see above.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.
greg kuechle
I didn't upgrade the kernel. The kernel supports multiple CPUs. The only
thing that I upgraded was named. I built it from the souce code.The older
version that came with the RedHat OS as a package uses all of the CPUs, yet
when I compile named on the system it will only see 1 CPU.
When I compile and run the following code:
#include <stdio.h>
#include <usistd.h>
int main()
{
printf("ncpus: %d\n" , sysconf((_SC_NPROCESSORS_ONLN))):
return(0);
}
The result is:
ncpus: 4
There seems to be a problem with the way the 9.4.2 code is getting built on
my RedHat systems.
I compiled using the following:
$INSTALL_DIR/configure --prefix=/opt/named --with-openssl --enable-threads
make
make install
I have three other servers that have the same problem. They are all running
RedHat es4.
These are production servers, so I require the use of all of the CPUs.
I also tryed starting named without the -n switch and only one CPU is
detected and one worker thread is started.
Thanks for any Help.
Greg.
On Mon, Mar 31, 2008 at 1:19 PM, Matus UHLAR - fantomas <uh...@fantomas.sk>
wrote:
Jeff Lightner
Typically on the older boxes during install it would build both an SMP
kernel and a non-SMP kernel. During boot grub would default to one
kernel or another but give you the opportunity to interrupt the boot and
pick the kernel. If you interrupted boot then told it to boot from the
kernel that doesn't have smp at the end of its name you're not doing
multi-processor. The fix for this is simply to reboot and be sure you
are booting from the smp kernel.
#include <stdio.h>
#include <usistd.h>
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------
Adam Tkac
> Hello,
> I have install bind 9.4.2 on a system with 4 CPUs running RedHat es4. I
> compiled named with the --enable-threads and used the -n 4 flag when I
> start named.
>
> Mar 31 10:12:24 ******** named[4897]: starting BIND 9.4.2 -t /opt/named
> -u named -n 4 -c /etc/named.conf
> Mar 31 16:12:24 ******** named[4897]: found 1 CPU, using 4 worker threads
>
> comes packaged with the OS.
> Here is the output from the logfile.
> Mar 24 11:34:13 ******** named[5877]: starting BIND 9.2.4
> Mar 24 11:34:13 ******** named[5877]: using 4 CPUs
>
>
>
> other CPUs once one CPU is up to 100% ?
>
>
>
I think you forgot mount /proc filesystem into chroot. You can try it again
with /proc mounted in chroot (for example $mount --bind /proc ${CHROOT}/proc)
Adam
--
Adam Tkac, Red Hat, Inc.
Jeff Lightner
Is this something required for later versions of BIND?
I have BIND 9.2.x on Linux systems in chroot environments but never had
to mount /proc there. Since /proc isn't a "real" filesystem I was
under the impression the kernel handled most of what needs to go there.
Exceptions would be the things one does to force updates in the rare
areas (e.g. SCSI changes) /proc allows that. What would BIND be doing
that requires it to directly access /proc?
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Adam Tkac
Sent: Tuesday, April 01, 2008 8:23 AM
To: greg kuechle
Cc: bind-...@isc.org
Subject: Re: Number of CPUs detected by Bind 9.4.2 on 4 CPU system
runningRedHat es 4.
Adam
greg kuechle
Thank you Adam,
That did the trick. I mounted /proc in chroot and restarted named.
I am still using the -n 4 switch. The log output is:
Apr 1 14:01:58 dnsserver-1 named[31533]: found 4 CPUs, using 4 worker
threads
When I run a ps -ef | grep name I only see one named process running. Is
this correct ?
I thought I would see 4 running.
Greg.
Jeff Lightner
environment and changing your SCSI setup or other things which is done
by echoing things into /proc/scsi/...? If it's really required should
it be a read only mount? The whole point of chroot is to limit what
can be accessed if the chroot environment is compromised. Giving direct
access to something like /proc seems counterintuitive to me.
I feel I'm missing something important here.
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of greg kuechle
Sent: Tuesday, April 01, 2008 11:09 AM
To: Adam Tkac
Cc: bind-...@isc.org
Subject: Re: Number of CPUs detected by Bind 9.4.2 on 4 CPU system
running RedHat es 4.
Thank you Adam,
Greg.
Matus UHLAR - fantomas
> Is this something required for later versions of BIND?
>
> I have BIND 9.2.x on Linux systems in chroot environments but never had
> to mount /proc there. Since /proc isn't a "real" filesystem I was
> under the impression the kernel handled most of what needs to go there.
> Exceptions would be the things one does to force updates in the rare
> areas (e.g. SCSI changes) /proc allows that. What would BIND be doing
> that requires it to directly access /proc?
seems /proc is needed for detecting the number of CPUs...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
Matus UHLAR - fantomas
> I'm sorry but doesn't this risk someone getting into your chroot
> environment and changing your SCSI setup or other things which is done
> by echoing things into /proc/scsi/...? If it's really required should
> it be a read only mount? The whole point of chroot is to limit what
> can be accessed if the chroot environment is compromised. Giving direct
> access to something like /proc seems counterintuitive to me.
I'm not sure if chrooted/vservered process can modify SCSI settings
(shouldn't imho) but it's better in this case to call named with "-n 4" or
whatever your number of CPUs/cores is.
the answer for OP here is, that the named will (hopefully) use all CPU's in
the system. The problem only comes from inability to detect the number of
CPUs, but the kernel will try to distribute load across all CPUs
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
Jeff Lightner
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Matus UHLAR - fantomas
Sent: Tuesday, April 01, 2008 11:25 AM
To: bind-...@isc.org
Subject: Re: Number of CPUs detected by Bind 9.4.2 on 4 CPU system
runningRedHat es 4.
On 01.04.08 10:52, Jeff Lightner wrote:
> Is this something required for later versions of BIND?
>
> I have BIND 9.2.x on Linux systems in chroot environments but never
had
> to mount /proc there. Since /proc isn't a "real" filesystem I was
> under the impression the kernel handled most of what needs to go
there.
> Exceptions would be the things one does to force updates in the rare
> areas (e.g. SCSI changes) /proc allows that. What would BIND be doing
> that requires it to directly access /proc?
seems /proc is needed for detecting the number of CPUs...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
Stulic,Damjan
that it was just fine couple of months ago. I rolled back all new
installs, but still have problems. Basically named core dumps on start
up:
/usr/sbin/named -c /ipam/local/dns/named.conf -g
Apr 01 10:32:55.525 starting BIND 9.2.4 -c /ipam/local/dns/named.conf -g
Apr 01 10:32:55.527 using 2 CPUs
Apr 01 10:32:55.575 loading configuration from
'/ipam/local/dns/named.conf'
Apr 01 10:32:55.577 listening on IPv4 interface lo, 127.0.0.1#53
Apr 01 10:32:55.580 listening on IPv4 interface eth0, 192.168.120.206#53
Apr 01 10:32:55.580 listening on IPv4 interface eth0, 192.168.120.220#53
Segmentation fault (core dumped)
tail -1 /var/log/messages
Apr 1 10:32:55 s_...@vldg-26.xxx kernel: named[27788] general
protection rip:2a95797795 rsp:414007e0 error:0
I tried stracing, but it didn't help much.. Google search on named
general protection rip did not help either.
rpm -qa | grep bind
bind-9.2.4-27.0.1.el4
bind-utils-9.2.4-28.el4
bind-libs-9.2.4-28.el4
uname -a
Linux vldg-26 2.6.9-67.0.1.ELsmp #1 SMP Fri Nov 30 11:57:43 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
Same versions running in production just fine.
Any pointers would be appreciated..
Thanks,
Damjan Stulic
IS Security Identity Management
Edward Jones
If you are not the intended recipient of this message (including attachments), or if you have received this message in error, immediately notify us and delete it and any attachments. If you no longer wish to receive e-mail from Edward Jones, please send this request to mess...@edwardjones.com. You must include the e-mail address that you wish not to receive e-mail communications. For important additional information related to this e-mail, visit www.edwardjones.com/US_email_disclosure
Jeff Lightner
of the adapter instances under /proc/scsi in Linux - I've done it many
times. That isn't the only thing that can be echoed into /proc to
change things - just the first one that comes to mind. By mounting
/proc in your chroot environment without doing it in read only mode
you've opened the door to anything that could be done in the real /proc.
Obviously permissions, users etc... in chroot can limit this for the
script kiddies but again the point in chroot is to contain damage in the
even the chroot environment IS compromised. Allowing access to key
areas of the base operating system such as /proc would seem to
invalidate that containment ideal.
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Matus UHLAR - fantomas
Sent: Tuesday, April 01, 2008 11:33 AM
To: bind-...@isc.org
Subject: Re: Number of CPUs detected by Bind 9.4.2 on 4 CPU system
running RedHat es 4.
On 01.04.08 11:20, Jeff Lightner wrote:
> I'm sorry but doesn't this risk someone getting into your chroot
> environment and changing your SCSI setup or other things which is done
> by echoing things into /proc/scsi/...? If it's really required should
> it be a read only mount? The whole point of chroot is to limit what
> can be accessed if the chroot environment is compromised. Giving
direct
> access to something like /proc seems counterintuitive to me.
I'm not sure if chrooted/vservered process can modify SCSI settings
(shouldn't imho) but it's better in this case to call named with "-n 4"
or
whatever your number of CPUs/cores is.
the answer for OP here is, that the named will (hopefully) use all CPU's
in
the system. The problem only comes from inability to detect the number
of
CPUs, but the kernel will try to distribute load across all CPUs
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
Chris Buxton
Chris Buxton
Professional Services
Men & Mice
On Apr 1, 2008, at 8:20 AM, Jeff Lightner wrote:
> I'm sorry but doesn't this risk someone getting into your chroot
> environment and changing your SCSI setup or other things which is done
> by echoing things into /proc/scsi/...? If it's really required should
> it be a read only mount? The whole point of chroot is to limit what
> can be accessed if the chroot environment is compromised. Giving
> direct
> access to something like /proc seems counterintuitive to me.
>
> I feel I'm missing something important here.
>
> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of greg kuechle
> Sent: Tuesday, April 01, 2008 11:09 AM
> To: Adam Tkac
> Cc: bind-...@isc.org
> Subject: Re: Number of CPUs detected by Bind 9.4.2 on 4 CPU system
> running RedHat es 4.
>
Adam Tkac
> Huh?
>
> Is this something required for later versions of BIND?
>
> I have BIND 9.2.x on Linux systems in chroot environments but never had
> to mount /proc there. Since /proc isn't a "real" filesystem I was
> under the impression the kernel handled most of what needs to go there.
> Exceptions would be the things one does to force updates in the rare
> areas (e.g. SCSI changes) /proc allows that. What would BIND be doing
> that requires it to directly access /proc?
After quick look into bind and glibc code /proc has to be mounted.
named calls sysconf(3) function and internal glibc implementation
looks like this:
__get_nprocs () {
..
FILE *fp = fopen ("/proc/stat", "rc");
if (fp != NULL) {
..
} else {
fp = fopen ("/proc/cpuinfo", "rc");
if (fp != NULL) {
..
}
..
}
return 1;
}
So if you don't have /proc mounted in chroot glibc is not able to get
number of CPUs and returns 1. When you don't need detect correct
number of CPUs (always use one CPU) then you don't have to mount /proc
Adam Tkac
> Looking for help. Bind in development environment just wont run. I know
> that it was just fine couple of months ago. I rolled back all new
> installs, but still have problems. Basically named core dumps on start
> up:
>
> /usr/sbin/named -c /ipam/local/dns/named.conf -g
> Apr 01 10:32:55.525 starting BIND 9.2.4 -c /ipam/local/dns/named.conf -g
> Apr 01 10:32:55.527 using 2 CPUs
> Apr 01 10:32:55.575 loading configuration from
> '/ipam/local/dns/named.conf'
> Apr 01 10:32:55.577 listening on IPv4 interface lo, 127.0.0.1#53
> Apr 01 10:32:55.580 listening on IPv4 interface eth0, 192.168.120.206#53
> Apr 01 10:32:55.580 listening on IPv4 interface eth0, 192.168.120.220#53
> Segmentation fault (core dumped)
>
> tail -1 /var/log/messages
> Apr 1 10:32:55 s_...@vldg-26.xxx kernel: named[27788] general
> protection rip:2a95797795 rsp:414007e0 error:0
>
> I tried stracing, but it didn't help much.. Google search on named
> general protection rip did not help either.
rip and rsp are values of instruction pointer and stack pointer
registers. Core file is far more useful. If you want fix this problem
you can open bug report in RH bugzilla (https://bugzilla.redhat.com/)
with core file attached.
Adam Tkac
> I'm sorry but doesn't this risk someone getting into your chroot
> environment and changing your SCSI setup or other things which is done
> by echoing things into /proc/scsi/...? If it's really required should
> it be a read only mount? The whole point of chroot is to limit what
> can be accessed if the chroot environment is compromised. Giving direct
> access to something like /proc seems counterintuitive to me.
>
> I feel I'm missing something important here.
>
You're right. It should be mounted read-only. But if named runs under
non-root user it is not needed because only root can change /proc
values (but as you wrote read-only is more secure).
Lars Hecking
[...]
> named calls sysconf(3) function and internal glibc implementation
> looks like this:
Not that I have looked at the code, but maybe bind should grab this info
before dropping privileges and going to jail ...
Adam Tkac
Yes, this will be the best long term solution. I'm going to prepare
simple patch to fix this problem.
Mark Andrews
/proc is also needed for IPv6 interface scanning.
This is a design fault in Linux.
The correct fix is to correct the design fault in the OS.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Jeff Lightner
the ro option but was still able to update my shmmax kernel parameter
echoing a new value to it. This was done as the root user but I thought
when mounted ro even root shouldn't be able to write to it. Is this a
bug an issue with the way --bind does the mount? Interestingly mount
did show the filesystem has the ro option after the mount.
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Mark Andrews
Sent: Tuesday, April 01, 2008 6:24 PM
To: Adam Tkac
Cc: Lars Hecking; bind-...@isc.org
Subject: Re: Number of CPUs detected by Bind 9.4.2 on 4 CPU system
runningRedHat es 4.