0

I've configured logging in my BIND9 server and I have 2 log files: 1) debug.log; 2) query.log. The second one is Okay. No complaints so far. But the first one is too verbose (too chatty) for me. Like 90% of what it says there I don't even understand. You get like 100's of thousands of text lines within couple of hours only. That's crazy! Here how it's set:

channel debug_log {
     file "/var/log/named/debug.log";
    severity debug 3;

If I understand it right, to make it less verbose (chatty), I can try debug 2 or simply debug (which defaults to debug 1). Right? The next level (less chatty) would be:

severity info; 

Right?

P.S. Here's my full logging section:

logging {

channel debug_log {
     file "/var/log/named/debug.log";
    severity info;
    print-category yes;
    print-severity yes;
    print-time yes;
};

channel query_log {
    file "/var/log/named/query.log";
    severity dynamic;
    print-category yes;
    print-severity yes;
    print-time yes;
};

category resolver { debug_log; };
category security { debug_log; }; 
category queries { query_log; };

};

  • Why did you turn the logging all the way up to debug 3 in the first place? Are you trying to debug something? If not, is there any other reason why you wanted this over the defaults? – Håkan Lindqvist Nov 1 '15 at 15:52
  • No, I don't want to debug anything. It's just that I didn't have any logging set up at all in the beginning and then I found a nice article online of how to set it. But in that article they didn't clarify all the details about the severity level and the amount of unneeded info I would be getting. I didn't have any defaults to begin with. I was sort of building the BIND9 config files from scratch myself. – Gregory Nov 1 '15 at 18:01
2

As a point of reference, if you do not specify any custom logging settings through named.conf the defaults are:

logging {
    category default { default_syslog; default_debug; };
    category unmatched { null; };
};

And the predefined channels are:

channel default_syslog {
    // send to syslog's daemon facility
    syslog daemon;
    // only send priority info and higher
    severity info;
};

channel default_debug {
    // write to named.run in the working directory
    // Note: stderr is used instead of "named.run" if
    // the server is started with the '-f' option.
    file "named.run";
    // log at the server's current debug level
    severity dynamic;
};

channel default_stderr {
    // writes to stderr
    stderr;
    // only send priority info and higher
    severity info;
};

channel null {
   // toss anything sent to this channel
   null;
};

Ie, if you do not touch logging settings whatsoever in your configuration file it will log at severity info to syslog.
If you were to turn on debug logging (rndc trace) it will also log at the current debug level to the file named.run in named's working directory.

If all you want is the default logging that would normally go to syslog but directly into in a separate file, info would be the severity for that.

If you are not debugging named, I don't see any reason to log at debug severity. Normal errors that are relevant to your typical operational troubleshooting are already logged with the default settings.

  • 1
    Since the OP mentioned a query log, it's also worth noting that the presence of a queries logging category will automatically enable querylog as if rndc querylog on had been invoked. To disable this behavior, set querylog no; in the global options block and enable it with rndc as needed. – Andrew B Nov 1 '15 at 21:46
  • I don't know... After I switched to info, both logs stopped doing anything (they're both empty). I added my logging section in its full into my original post. – Gregory Nov 2 '15 at 5:11
  • Sorry, had to re-start BIND. Now my second file gets the info (query.log), but debug.log is still empty. – Gregory Nov 2 '15 at 5:23
  • Has switched debug.log to notice, still no difference. query.log is getting the info, but debug.log is still empty. Looks like it needs to be done differently... – Gregory Nov 2 '15 at 5:32
1

For debug, the lowest values you can set is 1, which is less verbose than say 2 or above. Of course, you can set the debug value to 0 too, but that would mean you have disabled debugging.

You are correct, the next level or less chatty severity after debug would be info, followed by notice, warning, error and critical(only critical errors, thus much less chatty).

Read the severity section in this documentation

For the debug severity, you can also set it to dynamic, this is usefully when you want to make changes on the fly during testing phase or troubleshooting. Once set to dynamic, use the rndc trace to increment the value by one, or rndc notrace to set the debugging value to 0. You can also control the debug values using `rndc trace level.

Using the dynamic severity -

ns1 bind # rndc status
...
debug level: 0
..

ns1 bind # rndc trace 2
ns1 bind # rndc status
...
debug level: 2
...
ns1 bind # rndc trace 0
ns1 bind # rndc status
...
debug level: 0
...
  • Thanks! Well, I was thinking to take it gradually from debug 3 to 2 and then debug 1 just to see the difference. Then I could try info, I guess. I wonder what's the actual difference between those levels. It's something that is still a mystery to me. – Gregory Nov 1 '15 at 18:04
  • I was thinking (let me know if it's at all possible), to comment out the lines regarding debug.log (until I really need to debug BIND9) in the logging section... – Gregory Nov 2 '15 at 8:29
  • Set it to severity debug 0, that will disable it. Whenever you need to do troubleshooting, increase the number from 0 to 1, 2 etc. – Daniel t. Nov 2 '15 at 21:15
  • I don't know how to insert code in comments, but you can see the logging section of named.conf.local in my original post above (except that now the severity of debug.log is set to notice as opposed to info as above). I've already understood about the severity debug and when it should be turned on. Now I'm asking about the normal operation. Does my logging configuration is Okay then? What I'm getting in my debug.log right now is this line "Date Time security: warning: using built-in root key for view _default" . Does it mean that both files are getting the info that they should be getting? – Gregory Nov 3 '15 at 1:43
  • Yes, since you are seeing warning and warning is above info, the files are getting the info severity. If you don't want to see warning then use severity error or critical. As for your logging configuration, your setup is a bit strange in that you are sending both resolver and security category into the same debug.log file. I would create two separate channels for security and resolver and send the logs to two different files. Check stackoverflow.com/questions/11153958/… for a granular channels. – Daniel t. Nov 3 '15 at 2:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.