Weird Named error...

[Braun Brelin]

Okay,

I'm trying to run named so that it won't write anything to syslog.
I've got a logging statement in my named.conf file that looks like this:

logging {
        channel simple-log {
            file  "/var/log/named.log"  versions 3 size 5m;
            severity info;
            print-time yes;
            print-category yes;
        };
        category default {
           simple_log;
        };
        category config {
           simple_log;
        };
        category client {
           simple_log;
        };
        category general {
           simple_log;
        };
};

I can't, however, get named to stop logging to syslog on startup.  How can
I get named to stop logging *anything* to syslog and to log to my
named.log file instead?

Thanks,

Braun Brelin

> I'm running named as follows:
>
> /usr/sbin/named -g -u named (works)
> /usr/sbin/named <any param except -g> -u named (fails)
>
> As far as I know, it's not running chroot or in a sandbox.
>
>
> Hum...As I write this, I'm thinking that maybe syslog is the problem here.
> The only major difference is that -g writes logs to stderr rather than to
> syslog...
>
>
> Braun Brelin
>
>
>> What is the complete command line you are using?  Are you running
>> chroot, and/or in a sandbox?  The sigsuspend() system call is
>> understandable if named is launched as foreground and ^Z suspended.
>> ;=)  But, you don't need to run in the foreground.  I am currently only
>> running named as
>> <path to named>/named -c <path to configs>/named.conf.
>>
>> We have run into similar behaviour using Bind8.4.7 on Red Hat AS3.0. In
>> our case, the behaviour came as we were rotating logs.  The system load
>> was light ~300qps.  We log all of our transactions and shuttle them out
>> using syslog.  Anyway, as logs were renamed, new files created, and a
>> SIGHUP sent to syslog to re-open all file handles, named seemed to block
>> on IO.  The process seemed to be wedged and had to be killed off and
>> started fresh.  Since then, we have not been able to recreate/simulate
>> the problem.  We do believe that the problem is OS and Syslog
>> implementation dependent.  NB;  Synchronous file system writes (default
>> RedHat syslog behaviour) carry a high penalty and is easily seen under
>> load -  Turn off with '-' (minus) in front of the file name for syslog.
>> /etc/syslog.conf:
>>     local0.*                        -/var/log/named.log
>>
>> On an offline box using Bind9.3.1 and queryperf, we were driving the
>> box  to 4700 qps and found that things got pretty spongy when the input
>> queue (netstat -an | grep 53) got to about 65000 packets in the queue.
>> But still, named was always able to dig itself out.  Bind performance
>> returned to normal when the input queues got to below 62000 packets.
>>
>> Tim Peiffer
>> University of Minnesota
>>
>> Braun Brelin wrote:
>>
>>>Hello all,
>>>
>>>I have a strange named problem which I'm hoping someone can help me
>>> solve.
>>>I'm running a RedHat 7.2 system with Bind 9.2.1.
>>>
>>>Currently, BIND only resolves names if I run it with the -g option.
>>>
>>>I.e. named -g -u named will resolve names via nslookup or dig.
>>>
>>>If I run it normally i.e. via /sbin/service or /etc/init.d/named start
>>>it will still show up as a process (actually it shows up as 4 processes
>>> in
>>>the process table) but nslookup timesout with a no connection error.
>>>
>>>I ran strace named -f -u named just to see if I could find out what was
>>>happening.  It seems as though named is stuck in a sigsuspend() system
>>>call apparently waiting for some signal or another to continue.
>>>
>>>The only thing that has changed on the box was that the /var fs filled
>>> up
>>>yesterday (It's since been cleared).  All of the zone files look normal.
>>>
>>>Has anyone seem this sort of behavior from named before?
>>>
>>>Thanks,
>>>
>>>Braun Brelin
>>>
>>>
>>>
>>
>
>