I have install net-dns/bind-9.3.2. Normaly when you want to stop bind service, you use the "/etc/init.d/named stop" command. However, this one failed with [!!] and the service is always running. There is no particulary configuration to do this. After reading the /etc/init.d/named script, I noticed that the stop() method doesn't use the rndc tools when a $KEY is defined as is done in reload() method. But it uses only the classic "start-stop-daemon --stop ..." command as we can see: stop() { ebegin "Stopping ${CHROOT:+chrooted }named" checkconfig || return 2 start-stop-daemon --stop --quiet --pidfile $PIDFILE \ --exec /usr/sbin/named -- stop eend $? } Nevertheless, according to "man named", we have: "In routine operation, signals should not be used to control the nameserver; rndc should be used instead.". So I corrected the old stop() method like the following: stop() { ebegin "Stopping ${CHROOT:+chrooted }named" checkconfig || return 2 if [ -f $KEY ] ; then rndc -k $KEY stop &>/dev/null else start-stop-daemon --stop --quiet --pidfile $PIDFILE \ --exec /usr/sbin/named -- stop fi eend $? } And now I can stop the named service without have a [!!] error. Is this the right solution? Regards, Gr
I have install net-dns/bind-9.3.2. Normaly when you want to stop bind service, you use the "/etc/init.d/named stop" command. However, this one failed with [!!] and the service is always running. There is no particulary configuration to do this. After reading the /etc/init.d/named script, I noticed that the stop() method doesn't use the rndc tools when a $KEY is defined as is done in reload() method. But it uses only the classic "start-stop-daemon --stop ..." command as we can see: stop() { ebegin "Stopping ${CHROOT:+chrooted }named" checkconfig || return 2 start-stop-daemon --stop --quiet --pidfile $PIDFILE \ --exec /usr/sbin/named -- stop eend $? } Nevertheless, according to "man named", we have: "In routine operation, signals should not be used to control the nameserver; rndc should be used instead.". So I corrected the old stop() method like the following: stop() { ebegin "Stopping ${CHROOT:+chrooted }named" checkconfig || return 2 if [ -f $KEY ] ; then rndc -k $KEY stop &>/dev/null else start-stop-daemon --stop --quiet --pidfile $PIDFILE \ --exec /usr/sbin/named -- stop fi eend $? } And now I can stop the named service without have a [!!] error. Is this the right solution? Regards, Grégoire Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.5-r2, 2.6.14-hardened-r1 i586) ================================================================= System uname: 2.6.14-hardened-r1 i586 AMD-K6(tm) 3D processor Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-pc-linux-gnu" CFLAGS="-mtune=k6-2 -O2 -pipe" CHOST="i386-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=k6-2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://mirror.ovh.net/gentoo-distfiles/ ftp://mirror.ovh.net/gentoo-distfiles/" LC_ALL="fr_FR@euro" LINGUAS="fr en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.fr.gentoo.org/gentoo-portage" USE="x86 apache2 apm berkdb bitmap-fonts bzip2 crypt dri expat foomaticdb fortran gdbm gstreamer ipv6 ldap libg++ libwww mad ncurses nls pam perl python readline sdl ssl tcpd truetype truetype-fonts type1-fonts udev xml2 zlib linguas_fr linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, PORTDIR_OVERLAY
Please, don't restrict bugs without any reason.
This init script is slightly broken anyway as if you change pidfile location when it's already running AND/OR enable a chroot then it won't stop either. init script should save these (save_options chroot "${CHROOT}") on a successful start and restore (CHROOT="$(get_options chroot)") on stop. I disagree that rdnc should be used as again, the key and/or location may be changed between start/stop calls.
That's right, there is an issue with the $KEY location two. However $KEY could be specified in the /etc/conf.d/named file rather than directly in the init script. For the $PIDFILE variable, it seems than the suggestion from bug #107724 doesn't support the "include" instruction. It's maybe why the basic init script doesn't work on my config. Indeed I use 'include "/etc/bind/named.conf.options";' and my "pid-file" instruction is in this named.conf.options file. Nevertheless my "pid-file" instruction is: 'pid-file "/var/run/named/named.pid";' and in /etc/conf.d/named we have: 'PIDFILE="${CHROOT}/var/run/named/named.pid"'. I think the main issue turn around the following sentence from 'man named': "In routine operation, signals should not be used to control the nameserver; rndc should be used instead."
fixed stop() in 9.{2.6,3.2}-r5 init's, thanks for suggestion.
I have a suggestion: The use of rndc should definitely be an option that is set in the conf.d/named file, and this is for a few reasons as I see it: 1) I suppose that most people run named locally, start-stop-daemon is simpler and less error prone in this case: By using rndc, stopping the daemon involves a TCP connection, which means other services could be involved: tcp wrappers, firewalls, kernel security measures. By using this inherently more complicated measure by default, we are creating more problems by default. We must minimize rc-script assumptions as much as possible. 2) init.d scripts usually define variables in conf.d files, it's just more predictable. It's also probably reasonable to assume that most users will not be changing the PID or the KEY variables while the daemon is running, so the the clarity gained by moving these variables over to conf.d is likely well worth it.
