# named start dying silently

## woe

Hello everyone,

After searching the web, IRC, and the forums, for any relevant answer to the problem, here it comes  :Wink: 

The fact is BIND 9.2.2-r3 (from emerge) seems to be unhappy on my box, and refuse to start through /etc/init.d/named script.

Starting BIND directly from bash using /usr/sbin/named -f -c /etc/bind/named.conf perfectly works (I'm not discussion any configuration issues on BIND), and logging to [b]/var/log/named.log[b] is functionnal.

Anyway, starting it from the RC Script is another story. I don't know if this is a bind problem, or some runscript problem, because of the following fact: I did put "echos" everywhere in the script (to be precise, between every line of the "start ()" procedure), but no one shows up when called.

Although any other procedure works (stop returns an error, restart also, reload doesn't understand : they are not working, but they are alive), the start one seems to be completely dead. I enter it, then I can re-enter it, and so on : no log, no process left up, no PID file created, nothing I can track or have a record of.

Does someone have an idea about the way I could repair this in order to make named to work once for all ?

I'll be watching the thread carefully if some additional info is needed.

----------

## steveb

 *woe wrote:*   

> Hello everyone,
> 
> After searching the web, IRC, and the forums, for any relevant answer to the problem, here it comes 
> 
> The fact is BIND 9.2.2-r3 (from emerge) seems to be unhappy on my box, and refuse to start through /etc/init.d/named script.
> ...

 

you don't need to add echo statement to the init script! go and edit /etc/conf.d/named and add to the OPTIONS an debug level and then start bind with the init script and keep watching your log for infos, why it does not start.

i think that the problem is the creation of the pid file in /var, but i could be wrong.

cheers

SteveB

----------

## woe

I forgot to mention that debug level is already set to 9, quiet mode from start-stop-daemon replaced by verbose mode.

When starting from commandline, the pid problem was here, but I had some logs, some proves that the program have started "once upon a time". Now, there isn't anything that says me it tried.

Anyway, I'll try to solve the pid problem first - perhaps it will resolve the hole thing. I'll post further information asap.

Thanks for answering steveb !

Edit:

Ok, I had to chown some things in order to remove those annoying messages in the logs. Calling named from the commandline is now working perfectly, and calling it from init.d is failing as before, without saying/logging anything : it seems that start-stop-daemon is hiding everything that comes from named anyway - since even with the -g flag (which print every logline to stdout) doesn't change anything.

----------

## woe

some investigation later, it appears definitely that this script is behaving strangely.

start-stop-daemon seems to be working fine : calling start-stop-daemon --verbose --start --exec /usr/sbin/named -- -c /etc/bind/named.conf -d 9 -g -u named from the shell works perfectly.

I removed the -d9 and -g switches from /etc/conf.d/named file because they are nonsense for something that should run silently as a service.

Anyway, the script keeps saying nothing, exiting after 1 second or so, leaving nothing behind (logs or something.)

----------

## Chris W

My first observation is that you using an ebuild marked unstable/experimental on most platforms (stable on ppc and ppc64 only at time of writing).  You don't specify the platform but if you are not using either of the stable platforms you should consider downgrading.

Other things to check:Does the script indicate a failed start [!!] or an OK start [OK]?

You say the script doesn't leave logs, but does it leave a named process running?  

The init.d script sources /etc/conf.d/named - have you set anything in this file?

Are you trying to run in a chroot jail - have you set this up?

Does /var/bind exist?  Is it owned and writable by named:named?

Does /var/run/named exist? Is it owned and writable by named:named?  This is where the pid file will appear.

Does /etc/init.d/named match the file /usr/portage/net-dns/files/named.rc6?

----------

## woe

 *Chris W wrote:*   

> Does the script indicate a failed start [!!] or an OK start [OK]?
> 
> You say the script doesn't leave logs, but does it leave a named process running?  
> 
> The init.d script sources /etc/conf.d/named - have you set anything in this file?
> ...

 

In order:

 The script doesn't indicate anything, neither [!!] or [OK].

 No named process left behind (nothing listening on 53/953 thanks to netstat, and nothing at all thanks to ps auxw | grep named)

 In /etc/conf.d/named, I've added some flags in OPTIONS variable, which are "-c /etc/bind/named.conf -u named" - those seems to be the default, but it was to be sure.

 No, I'm not trying to run in a chroot jail, nothing was set up to do this.

 /var/bind exists and is owned by named:named

 /var/run/bind exists and is owned by named:named, writable for the owner. No PID file in there anyway.

 No it wasn't matching, because I changed some things in the previous one, trying to trap errors. I didn't succeed anyway. Reverted my /etc/init.d/named script to the /usr/portage/net-dns/bind/files/named.rc6 script haven't changed anything to the problem.

About downgrading, the solution seems a bit radical to me - just because the init script doesn't work properly. The named since to work fine when called from commandline.

----------

## steveb

okay... i am now going to install bind-9.2.2-r3.ebuild on my box. let me see if this is an bind-9.2.2-r3.ebuild issue.

cheers

SteveB

----------

## Chris W

 *Quote:*   

> The script doesn't indicate anything, neither [!!] or [OK]. 

 

This is truly odd because the very first thing the script does is output a string:

```
# /etc/init.d/named start

 * Starting named...
```

which comes from the code:

```
start() {

        ebegin "Starting ${CHROOT:+chrooted }named"

        checkconfig || return 1

        start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -n $CPU $OPTIONS ${CHROOT:+-t $CHROOT}

        eend $?

}
```

in the script.  The "eend" function prints [ok] or [!!] based on the return code of start-stop-daemon - this isn't being reached.  The only other exit point is the checkconfig function returning FALSE.   As best I can tell it will never do that.

There's no need to specify "-c /etc/bind/named.conf" or "-u named" in the /etc/conf.d/named file because that is the default behaviour of the init.d script/named.  However, adding those options did not cause a problem in my installation.  This is my working, and completely default, conf.d file:

```
# cat /etc/conf.d/named

# Set various named options here.

#

OPTIONS=""

# Set this to the number of processors you have.

#

CPU="1"

# If you wish to run bind in a chroot, run:

# ebuild /var/db/pkg/net-dns/<bind version>/<bind-version> config

# and un-comment the following line.

# You can specify a different chroot directory but MAKE SURE it's empty.

# CHROOT="/chroot/dns"
```

What are the permissions on the /etc/bind/named.conf and /var/bind/* files?

----------

## woe

the permissions:

in (/etc/bind)

```
-rw-r--r--  1 named named 809 Apr 11 22:44 named.conf

```

in (/var/bind)

```
drwxr-xr-x   4 named named 4096 Apr 11 22:54 .

drwxr-xr-x  16 root  root  4096 Apr 10 05:51 ..

-rw-r--r--   1 named named 2499 Apr  9 23:51 named.ca

drwxr-xr-x   2 named named 4096 Mar 29 20:22 pri

lrwxrwxrwx   1 named named   23 Apr  9 23:51 root.cache -> ../../var/bind/named.ca

drwxr-xr-x   2 named named 4096 Mar 29 20:22 sec

```

I find as strange as you that nothing is prompted. I tried to add some "echo" statements before ebegin, but it haven't prompted anything either.

----------

## mvb88

Hi,

I had a similar problem as described on top of this thread with BIND 9.2.2-r2. Although maybe not related. Named died silently where it had worked before. Only during boot there was an error message: could not open /dev/random. Dmesg should give you the same. Changing the permission to rw of /dev/random fixed it.

Now what puzzled me was: what changed the permission and why was there no error at all when starting named from the prompt.

I have not looked into what the startup script does. but I guess it looks for some reason at /dev/random where named does not look at that when you start it from the prompt with -f.

The only error I got from the init.d script was: Named already started, which was not the case. Hope this may help.

----------

## Crymson

 *Chris W wrote:*   

> 
> 
> [*]Does /var/bind exist?  Is it owned and writable by named:named?
> 
> [*]Does /var/run/named exist? Is it owned and writable by named:named?  This is where the pid file will appear.
> ...

 

I also am having the pid file problem.  When I boot, it says [OK], even though it doesn't actually initialize.  Searching through the logs, I found this:

```

couldn't open pid file '/var/run/named/named.pid': Permission denied

```

I'm guessing here that /var/run/named is **NOT** owned and writable by named:named.  So, how do I check that?  Also, if that isn't the case, how do I fix it?  The rest of your list seems to be all good.  (I can also start this up from the command line, but the script borks out on me).

Thanks!!

----------

## Crymson

Well, problem was, my /var/run/named directory was root:root.  chown to named:named and wow, what do you know?  It works.

Total n00b mistake.  N/M

----------

## woe

well, permissions are correctly set up here for /var/run/named - I do launch named by hand now, since the server reboots approximatively every two monthes, it's not really a problem.

Anyway, pretty annoying that the init script doesn't work. Worse, the "bug" extented to more and more scripts as the time goes.

Still have no clue, and start-stop-daemon isn't very verbose when it exits, even with --verbose flag. Too bad...

----------

## Crymson

I can't speak about the other errors, and it migrating to other scripts, but the only way I was able to track down the named bug was by viewing the boot log in /var/log/messages.

The weird thing is, when the computer boots, it says "Starting named... [Ok]", even though it failed!

My suggestion, to find the error in named (along with the other errors hopefully) is delete the messages file in /var/log (to eliminate the other old stuff), reboot, then go look at it in your favorite editor.  It'll show you exactly what each script is trying to do, and where it bails.

I hope that helps, it helped me to isolate my problem.

----------

## eltech

I am having the same problem as the original poster .. .. i cant use the init script.. but i can run from the shell .. but not using the switch "-u named" it wont start if i use "-u named"

If using the init script, bind dies silently with no alert ..

nothing at all is in the logs .. 

its a mess ..

directories are  by named:named ..

bug filed Here..

----------

## eltech

BUMP!

----------

## woe

Sorry to ask for that, but is your syslog correctly setup to write bind logs somewhere ?

It won't start if you use "-u named", but what does it do then, please attach some error message or something.

Check the ownership of /var/bind /var/run/named and every file in them.

----------

## eltech

 *woe wrote:*   

> Sorry to ask for that, but is your syslog correctly setup to write bind logs somewhere ?
> 
> It won't start if you use "-u named", but what does it do then, please attach some error message or something.
> 
> Check the ownership of /var/bind /var/run/named and every file in them.

 i stated it all in the post and in the bug ..

 *Quote:*   

> 
> 
> Posted: Sat May 29, 2004 5:15 pm    Post subject:     
> 
> --------------------------------------------------------------------------------
> ...

 

i will add that directories and files are named by named:named ..

Logs are setup correctly according to help in #gentoo .. it writes to /var/log/syslog.

Errors were listed in the filed bug, take a look .. 

```

Named wont start as user "named" -u named, init script wont start named either. It can only be started from the CLI/shell /usr/sbin/named .. /var/named /var/bind and /etc/bind are named:named

the binary /usr/sbin/named  is root:root

Reproducible: Always

Steps to Reproduce:

1.on boot up named starts but it silently dies ..

2./etc/init.d/named start

3./etc/init.d/named restart/stop

Actual Results:  

/etc/init.d/named start

 * Starting named...

  [ ok ]

But it dies electly ..

/etc/init.d/named start

 * WARNING:  "named" has already been started.

Its not really started

/etc/init.d/named stop 

  [ !! ]ing named...

Cant stop it ..

```

What else is needed ..

----------

## prior_philip

try

/etc/init.d/named zap

/etc/init.d/named start

Regards

----------

## eltech

 *prior_philip wrote:*   

> try
> 
> /etc/init.d/named zap
> 
> /etc/init.d/named start
> ...

 

My fault.. i should have included that i have tried this .. i have done it all ..

i use that syntax to stop and reset named when restart or stop fail

if i then try to start named after zap .. 

```

/etc/init.d/named start 

 * Starting named... 

  [ ok ] 

But it dies electly .. 
```

Pu it this way .. the init script is a problem, but whats even more a problem is running named as user named ..

running as root in shell like below

/usr/sbin/named

works fine ..

```

tcp        0      0 192.168.0.100:53        0.0.0.0:*               LISTEN      6128/named          

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      6128/named   
```

----------

## nobspangle

I had a problem identical to this on a gentoo box, named would start from the command line but not from the script. In the end I deleted my named.conf and started again. Can't remember exactly what was wrong but it was definatley a problem there.

----------

## eltech

 *nobspangle wrote:*   

> I had a problem identical to this on a gentoo box, named would start from the command line but not from the script. In the end I deleted my named.conf and started again. Can't remember exactly what was wrong but it was definatley a problem there.

 Deleting the named.conf would seem to make sense to me if named wouldnt even start .. but thats not the case, it runs with no problem from CLI

my named.conf is correct .. no problems ..

----------

## woe

run named from the CLI with the exact same parameters as the one in the init.d/named script (consider also the optional parameters you may have specified in conf.d/named), enable some verbose/debug output, and see what you get, send us back the result, and it may help.

----------

## eltech

 *woe wrote:*   

> run named from the CLI with the exact same parameters as the one in the init.d/named script (consider also the optional parameters you may have specified in conf.d/named), enable some verbose/debug output, and see what you get, send us back the result, and it may help.

 

Thanks for the response ..

Where would i put these parametters? 

What file?

What flags/switches? 

Where will it write to?

Thanks in advance ..

----------

## woe

 *eltech wrote:*   

> (1) Where would i put these parametters? 
> 
> (2) What file?
> 
> (3) What flags/switches? 
> ...

 

(1) You know, typing "named -blah1=doh -v" in CLI

(2) I don't spot the word file in my previous message. What are you asking for ?  :Shocked: 

(3) It's up to you to open the init.d/script and find them. I don't know what is causing the problem, but according to what you say, it's IN the script, so let's redo what the script does by HAND, to trap the bug.

(4) See (2)

----------

## eltech

 *woe wrote:*   

>  *eltech wrote:*   (1) Where would i put these parametters? 
> 
> (2) What file?
> 
> (3) What flags/switches? 
> ...

 DOH! .. follow the conversation.. lol

We are talking about the debug situation .. so associate it with the questions .. 

what are the debugging switches .. where do you put them????????? bah ..

anyway .. 

the init script reads as below.

```

#!/sbin/runscript

# Copyright 1999-2004 Gentoo Technologies, Inc.

# Distributed under the terms of the GNU General Public License v2

# $Header: /home/cvsroot/gentoo-x86/net-dns/bind/files/named.rc6,v 1.14 2004/03/04 19:17:25 vapier Exp $

opts="start stop reload restart"

depend() {

        need net

        use logger

        provide dns

}

checkconfig() {

        if [ ! -f ${CHROOT}/etc/bind/named.conf ] ; then

                eerror "No ${CHROOT}/etc/bind/named.conf file exists!"

        fi

        # In case someone doesn't have $CPU set from /etc/conf.d/named

        if [ ! $CPU ] ; then

                CPU=1

        fi

        if [ $CHROOT -a -d $CHROOT ] ; then

                PIDFILE="${CHROOT}/var/run/named/named.pid"

                KEY="${CHROOT}/etc/bind/rndc.key"

        else

                PIDFILE="/var/run/named/named.pid"

                KEY="/etc/bind/rndc.key"

        fi

}

start() {

        ebegin "Starting ${CHROOT:+chrooted }named"

        checkconfig || return 1

        start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -n $CPU $OPTIONS ${CHROOT:+-t $CHROOT}

        eend $?

}

stop() {

        ebegin "Stopping ${CHROOT:+chrooted }named"

        checkconfig || return 2

        start-stop-daemon --stop --quiet --pidfile $PIDFILE \

                --exec /usr/sbin/named -- stop

        eend $?

}

reload() {

        checkconfig || return 3

        if [ ! -f $PIDFILE ] ; then

                /etc/init.d/named start &>/dev/null

                exit

        fi

        if [ -f $KEY ] ; then

                ebegin "Reloading named.conf and zone files"

                rndc -k $KEY reload &>/dev/null

                eend $?

        else /etc/init.d/named restart &>/dev/null

        fi

}

restart() {

        svc_stop

        svc_start

}
```

if i run 

/usr/sbin/named -u root -n 1 from CLI named runs and shows

tcp        0      0 192.168.0.100:53        0.0.0.0:*               LISTEN      7184/named          

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      7184/named    

if i start in CLI like /usr/sbin/named -u named -n 1 i dont see any errors .. and netstat shows nothing ..

i dont have chroot setup .. in conf.d/named

----------

## woe

According to man named, I would advise:

-f switch : in order to prevent named going in the background. that way you will now if it crashes on start or not.

-d 10 : well, man isn't very explicit about this, but 10 should be more than

the max level of verbosity.

-g : forces all output to stderr

I would also advise to change your syslog settings during the process, in

order to prevent named output to get into any file (who know, it could be

very disk consuming - and if needed, you could reactivate it later), and

redirect /dev/log to a console, say tty12 (which is a nice idea for everytime because you will be able to see latest /dev/log without any effort).

(snip)

 *Quote:*   

> DOH! .. follow the conversation.. lol

 

I do, or at least, I try to. 

(/snip)

And about your init script, you can clearly see this

```
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -n $CPU $OPTIONS
```

which mean big trouble if you cannot start named with -u named.

Removing this should do the trick - anyway, you SHOULD NOT let this

program run as superuser, and SHOULD try to make it run as named.

----------

## eltech

ok .. lets see  :Smile:  ..

/etc/conf.d/named has the following options ..

```

OPTIONS="-f -d 10 -g"
```

```

root@pcns etc # /etc/init.d/named start

 * Starting named...

Jun 01 17:29:56.434 starting BIND 9.2.2 -u named -n 1 -f -d 10 -g

Jun 01 17:29:56.434 using 1 CPU

Jun 01 17:29:56.437 loading configuration from '/etc/bind/named.conf'

Jun 01 17:29:56.438 set maximum stack size to 4294967295: success

Jun 01 17:29:56.438 set maximum data size to 4294967295: success

Jun 01 17:29:56.438 set maximum core size to 4294967295: success

Jun 01 17:29:56.438 set maximum open files to 1024: success

Jun 01 17:29:56.438 listening on IPv4 interface lo, 127.0.0.1#53

Jun 01 17:29:56.438 clientmgr @0x8095b38: create

Jun 01 17:29:56.438 clientmgr @0x8095b38: createclients

Jun 01 17:29:56.438 clientmgr @0x8095b38: create new

Jun 01 17:29:56.438 client @0x80ac7f0: create

Jun 01 17:29:56.439 clientmgr @0x8095b38: createclients

Jun 01 17:29:56.439 clientmgr @0x8095b38: create new

Jun 01 17:29:56.439 client @0x80ae538: create

Jun 01 17:29:56.439 listening on IPv4 interface eth0, 192.168.0.100#53

Jun 01 17:29:56.439 clientmgr @0x80b02f0: create

Jun 01 17:29:56.439 clientmgr @0x80b02f0: createclients

Jun 01 17:29:56.439 clientmgr @0x80b02f0: create new

Jun 01 17:29:56.439 client @0x80b0670: create

Jun 01 17:29:56.439 clientmgr @0x80b02f0: createclients

Jun 01 17:29:56.439 clientmgr @0x80b02f0: create new

Jun 01 17:29:56.439 client @0x80b2478: create

Jun 01 17:29:56.440 res 0x80b9a58: create

Jun 01 17:29:56.440 Cleaning interval for adb:  8 buckets every 30 seconds, 1009 buckets in system, 3600 cl.interval

Jun 01 17:29:56.441 dns_requestmgr_create

Jun 01 17:29:56.441 dns_requestmgr_create: 0x80ceb80

Jun 01 17:29:56.441 dns_requestmgr_whenshutdown

Jun 01 17:29:56.441 replacing zone database

Jun 01 17:29:56.441 replacing zone database

Jun 01 17:29:56.441 command channel listening on 127.0.0.1#953

Jun 01 17:29:56.442 ignoring config file logging statement due to -g option

Jun 01 17:29:56.442 couldn't open pid file '/var/run/named.pid': Permission denied

  [ !! ]7:29:56.442 exiting (due to early fatal error)
```

Seems to be a pid file problem?

Note the location the pid is suppose to be runnin from .. 

PIDFILE="${CHROOT}/var/run/named/named.pid"

----------

## Chris W

The PIDFILE environment variable is a bit of a red herring.  It is set but not used when starting the named process (it is used elsewhere).  The /usr/sbin/named executable defaults to writing in /var/run/named.pid (see man named) but this behaviour can be overridden in /etc/bind/named.conf.   What you want is this in /etc/bind/named.conf: 

```
options {

... existing options

    pid-file "/var/run/named/named.pid";

}
```

AFAICT this is part of the default configuration file installed with Bind 9.2.2-r2 and 9.2.3.  The default file can be found at /usr/portage/net-dns/bind/files/named.conf-r2.

----------

## eltech

 *Chris W wrote:*   

> The PIDFILE environment variable is a bit of a red herring.  It is set but not used when starting the named process (it is used elsewhere).  The /usr/sbin/named executable defaults to writing in /var/run/named.pid (see man named) but this behaviour can be overridden in /etc/bind/named.conf.   What you want is this in /etc/bind/named.conf: 
> 
> ```
> options {
> 
> ...

 

!!!!!!!!!!!!!!!!!!!!!!!!

There we go ... !

That worked .. but it seems that there are some errors .. like .. 

```

Jun 01 18:53:06.712 dns_request_destroy: request 0x40b0f910

Jun 01 18:53:06.712 req_destroy: request 0x40b0f910

Jun 01 18:53:06.712 requestmgr_detach: 0x80bb4b0: eref 1 iref 2

Jun 01 18:53:06.712 req_timeout: request 0x40b092f0

Jun 01 18:53:06.712 req_cancel: request 0x40b092f0

Jun 01 18:53:06.712 req_sendevent: request 0x40b092f0

Jun 01 18:53:06.712 zone myotherdomain.com/IN: notify to 141.158.xx.xx#53 failed: timed out

Jun 01 18:53:06.712 zone myotherdomain.com/IN: notify to 141.158.xx.xx#53: retries exceeded

Jun 01 18:53:06.712 dns_request_destroy: request 0x40b092f0

Jun 01 18:53:06.712 req_destroy: request 0x40b092f0

Jun 01 18:53:06.712 requestmgr_detach: 0x80bb4b0: eref 1 iref 1

Jun 01 18:53:07.222 req_timeout: request 0x40b0aa78

Jun 01 18:53:07.222 req_cancel: request 0x40b0aa78

Jun 01 18:53:07.222 req_sendevent: request 0x40b0aa78

Jun 01 18:53:07.222 zone mydomain.com/IN: notify to 141.158.xx.xx#53 failed: timed out

Jun 01 18:53:07.222 zone mydomain.com/IN: notify to 141.158.xx.xx#53: retries exceeded

Jun 01 18:53:07.222 dns_request_destroy: request 0x40b0aa78

Jun 01 18:53:07.222 req_destroy: request 0x40b0aa78

Jun 01 18:53:06.202 zone maindomain.com/IN: notify to 141.158.xx.xx#53 failed: timed out

Jun 01 18:53:06.202 zone maindomain.com/IN: notify to 141.158.xx.xx#53: retries exceeded

Jun 01 18:53:06.202 dns_request_destroy: request 0x40b07260

Jun 01 18:53:06.202 req_destroy: request 0x40b07260

Jun 01 18:53:06.202 requestmgr_detach: 0x80bb4b0: eref 1 iref 3

Jun 01 18:53:06.712 req_timeout: request 0x40b0f910

Jun 01 18:53:06.712 req_cancel: request 0x40b0f910

Jun 01 18:53:06.712 req_sendevent: request 0x40b0f910

Jun 01 18:53:06.712 zone customerdomain.org/IN: notify to 141.158.xx.xx#53 failed: timed out

Jun 01 18:53:06.712 zone customerdomain.org/IN: notify to 141.158.xx.xx#53: retries exceeded

zone nysdomain.com/IN: notify response from 66.111.42.130#53: REFUSED
```

My ip is the 141.158.xx.xx ip .. why is it refusing the notify or is everything ok?

All seems to be ok .. i can stop and start named with no problem .. 

lets see how long it will last .

Is there anyway to define a log file be recorded for everything named does?

thanks again ..

----------

## Chris W

You need to look at the logging {} block in /etc/bind/named.conf and the Bind 9 Adminstrator Reference Manual.

The notify errors at your address are possibly because you are blocking DNS requests on your external interface.  The meaning of the others will depend on your zone configuration.

----------

## eltech

 *Chris W wrote:*   

> You need to look at the logging {} block in /etc/bind/named.conf and the Bind 9 Adminstrator Reference Manual.
> 
> The notify errors at your address are possibly because you are blocking DNS requests on your external interface.  The meaning of the others will depend on your zone configuration.

 well the logging grammar has me confused .. i'd just like to log to a file (/var/log/bind.log) .. 

But ..

I am not bocking any DNS requests .. port 53 is forwarded on my IPCop box ..  this box is in the DMZ so forwarding should not even be needed .. but.. hmm   :Confused: 

----------

## eltech

BTW i have closed the bug also ..

Its here

----------

## Chris W

Something like: 

```
logging {

  channel "to_file" {

    file "/var/log/named.log";

    severity info;

  }

  channel "to_debug_file" {

    file "/var/log/named.debug";

    severity dynamic;

  }

  category "default" {

    "to_file";

    "to_debug_file";

  }

}
```

although I have not tested this.

----------

## eltech

 *Chris W wrote:*   

> Something like: 
> 
> ```
> logging {
> 
> ...

 Yea.. that doesnt work ..  :Smile:  .. its ok, you've done more then enough to help ..  thanks alot ..

----------

## snowbum

 *Chris W wrote:*   

> The PIDFILE environment variable is a bit of a red herring.  It is set but not used when starting the named process (it is used elsewhere).  The /usr/sbin/named executable defaults to writing in /var/run/named.pid (see man named) but this behaviour can be overridden in /etc/bind/named.conf.   What you want is this in /etc/bind/named.conf: 
> 
> ```
> options {
> 
> ...

 

Thanks Chris. This worked for me as well. It seems one needs to do this with the default bind ebuild. Maybe the ebuild should be edited to reflect this or the compile time options changed.

----------

