I've installed: [I] net-dns/bind Available versions: 9.4.3_p5 ~9.6.2_p2 ~9.7.0_p2-r1 ~9.7.1_p2 {berkdb dlz doc geoip gssapi idn ipv6 ldap mysql odbc postgres resolvconf sdb-ldap selinux ssl threads urandom xml} Installed versions: 9.4.3_p5(06:18:57 AM 07/20/2010)(berkdb ipv6 ssl -dlz -doc -idn -ldap -mysql -odbc -postgres -resolvconf -selinux -threads -urandom) Homepage: http://www.isc.org/software/bind Description: BIND - Berkeley Internet Name Domain - Name Server I can successfully invoke named with: /usr/sbin/named My configuration and zone files all check out and I've verified that my external zones are properly being served up with network-tools.com According to the named man pages, the syntax for named is: SYNOPSIS named [-4] [-6] [-c config-file] [-d debug-level] [-f] [-g] [-m flag] [-n #cpus] [-p port] [-s] [-S #max-socks] [-t directory] [-u user] [-v] [-x cache-file] When I try running /etc/init.d/named start I get: plug dns # /etc/init.d/named start * Starting chrooted named ... usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] [-m {usage|trace|record|size|mctx}] named: extra command line arguments [ !! ] plug dns # So I'm trying to debug why the daemon file fails and have run into the problem. I understand that the command line parameters are optional, so I should be able to invoke named specifying only the user and the jailed root, yet named complains "extra line arguments": plug dns # /usr/sbin/named -u named -t /chroot/named usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] [-m {usage|trace|record|size|mctx}] named: extra command line arguments plug dns # As I read the syntax of named's man page, I should be able to invoke named with whatever optional parameters.
Even trying to simply run the server in the foreground causes named to complain with "extra command line arguments": plug bind # /usr/sbin/named -f usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] [-m {usage|trace|record|size|mctx}] named: extra command line arguments plug bind # ps -A|grep name plug bind #
Uhm, please paste "qcheck -e net-dns/bind" (its part of portage-utils) as well as "/etc/init.d/named -d start"
As requested: plug ~ # /etc/init.d/named -d start * ERROR: wrong args ( -d ) * Usage: named { start|stop|reload|restart } * named without arguments for full help plug ~ #
As requested: plug ~ # qcheck -e net-dns/bind Checking net-dns/bind-9.4.3_p5 ... MD5-DIGEST: /etc/conf.d/named MD5-DIGEST: /etc/bind/named.conf MD5-DIGEST: /var/bind/pri/localhost.zone MD5-DIGEST: /var/bind/pri/127.zone * 354 out of 358 files are good plug ~ #
I can't reproduce this behaviour... Can you try "named -g" too?
As requested: plug ~ # /etc/init.d/named -g * ERROR: wrong args ( -g ) * Usage: named { start|stop|reload|restart } * named without arguments for full help plug ~ # /etc/init.d/named -g start * ERROR: wrong args ( -g ) * Usage: named { start|stop|reload|restart } * named without arguments for full help plug ~ # /usr/sbin/named -g usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] [-m {usage|trace|record|size|mctx}] named: extra command line arguments plug ~ #
Hm, sorry.. but dunno.. Is everything else fine on your system? As I said, I can't reproduce it, tested all versions on a few of my systems. named (not the init script) runs fine with either -f or -g. Can you show me your /etc/conf.d/named and emerge --info please? Are you logged in as root? Also please try a fresh bind installation without any modifications in the config files.. I think it doesn't matter but who knows..
I'll change the resolution to WORKSFORME until we got more informations.
Sorry I did not respond sooner, I have not had direct access to the server for 3 days and returned last night. plug sbin # pwd /usr/sbin plug sbin # named -f usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] [-m {usage|trace|record|size|mctx}] named: extra command line arguments plug sbin # named -g usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] [-m {usage|trace|record|size|mctx}] named: extra command line arguments plug sbin # I'm not seeing any indication of problems elsewhere on the server. I am doing cross compiling where the target is ARM (SheevaPlug, "Plug") and I emerge on the Plug using distributed cross-compiling (distcc) which compiles on an AMD quadcore. BIND seems to be working if I invoke it manually, e.g. "/usr/sbin/named". I did try a re-emerge just before your suggestion. I'm reticent to attach the configuration file as publishing it compromises the security of my installation. Is it possible to get the configuration file, or specific information in it, to you in a way it is not public?
I did preserve the ebuild staging, so have all the source code which I can grep through. I've only dabbled in C when necessary to tweak a source and am not sure which file might contain the code handling the line parameters. If you have any suggestions or leads, I could add some debugging lines wherever named is suppose to be reading the line parameters. Just a thought.
It should be in bin/named/main.c.
main.c looked fine. I suspended by distributed compile by remming out FEATURES="distcc" in make.conf and then re-emerged bind (forcing it to compile on the ARM processor); now /usr/sbin/named works with the parameters and /etc/init.d/named start commences without error. I'm concluding the problem introduced comes from cross compiling (to and AMD quadcore. For the record gcc on the ARM box (native) is: plug log # gcc -v Using built-in specs. Target: armv5tel-softfloat-linux-gnueabi Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/armv5tel-softfloat-linux-gnueabi/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.3/include --datadir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.3 --mandir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.3/man --infodir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.3/include/g++-v4 --host=armv5tel-softfloat-linux-gnueabi --build=armv5tel-softfloat-linux-gnueabi --disable-altivec --disable-fixed-point --without-ppl --without-cloog --with-float=soft --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.3/python --disable-libgcj --with-arch=armv5te --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3-r2 p1.2' Thread model: posix gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2) plug log # and gcc on the AMD quadcore is: hermes ~ # gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.4 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/python --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.4-r1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.4.4 (Gentoo 4.4.4-r1 p1.0, pie-0.4.5) hermes ~ # I had read previously that the compilers should be the same, I thought 4.4.3 vs. 4.4.4 would not be different enough, but I guess it is. If I have time, I could try reducing the GCC on the AMD to match the GCC on the ARM and then try cross-compiling and see if the problem reappears. I'm closing this as not a bug. Is this something the team that monitors cross-compiling might be interested in?
and, thank you for your help and time on this.
(In reply to comment #13) > and, thank you for your help and time on this. > You're welcome :) I would suggest to talk to someone via IRC first, not sure if they're interested... that might be a known problem.
