https://bugs.openldap.org/show_bug.cgi?id=9726 Quanah Gibson-Mount <quanah(a)openldap.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Assignee|bugs(a)openldap.org |smckinn(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 Quanah Gibson-Mount <quanah(a)openldap.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.1 |2.6.2 -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #2 from Shawn McKinney <smckinney(a)symas.com&gt; --- Will add the param descriptions and overview of new logger here: https://www.openldap.org/doc/admin26/tuning.html#Logging -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #4 from Howard Chu <hyc(a)openldap.org&gt; --- None of them do. Use -s0 or olcLoglevel 0 to turn off syslog, same as always. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #6 from Shawn McKinney <smckinney(a)symas.com&gt; --- (In reply to Howard Chu from comment #5) Confirms my observation. I'll explicitly point it out in the docs. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #8 from Shawn McKinney <smckinney(a)symas.com&gt; --- Confused by phrasing "and are unrelated to messages exposed by the loglevel configuration parameter". How are they unrelated to the loglevel setting? IOW - Doesn't loglevel always control the granularity of the messages, regardless of whether they are bound for stderr or the logfile? And yes, the 'logFileOnly' flag controls that behavior which is clearly pointed out in the man page and despite what was said on earlier comment. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #10 from Shawn McKinney <smckinney(a)symas.com&gt; --- (In reply to Quanah Gibson-Mount from comment #9) I must be way off the mark because my assumption, 'debug', we're talking about what gets routed to the (new) logfile. stderr messages are routed to syslog. In light of that, possibly faulty assertion, the loglevel setting controls the level of granularity sent to the debug log (in addition to syslog), per my observations. e.g. set loglevel 0, and no messages will be sent. loglevel -1 sends all. What do I have wrong here? Again, stderr is what gets routed to syslog -- ? So, if logfile-only on then it's debug only, and no messages sent to syslog (stderr), regardless of what the loglevel is set to. Obviously, I don't have a firm grasp of openldap log fundamentals. if I'm confused, others must be. So, this is opportunity to make it explicit. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #12 from Howard Chu <hyc(a)openldap.org&gt; --- (In reply to Shawn McKinney from comment #10) That's entirely backward. debuglevel controls messages to stderr. loglevel controls messages sent to syslog. The confusing part is that logfile specifies a file to receive debug messages, in addition to stderr. And then the logfile_only directive means debug messages only go to the logfile, and turns off writing to stderr. And then, because some pinheads are too stupid to use debuglevel and still want to use loglevel, but without syslog, the logfile_only directive additionally routes loglevel messages to the logfile instead of syslog. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #14 from Shawn McKinney <smckinney(a)symas.com&gt; --- Clarifications / Level Set (courtesy of Quanah) OpenLDAP's C code has two different types of logging: 1. "DEBUG" messages, which confusingly, are what loglevel controls: ``` # loglevel of ACL: aci.c: Debug( LDAP_DEBUG_ACL, "aciNormalizeRight: perms:attr need to be pairs in '%s'\n", action->bv_val ); # loglevel of STATS: delete.c: Debug( LDAP_DEBUG_STATS, "%s DEL dn="%s"\n", # etc ``` 2. The actual debug messages, that only (normally) go to stderr: like ``` slapmodify.c: fprintf( stderr, "%s: could not %s entry dn="%s" " or (avoiding commandline tools) syncrepl.c: fprintf(stderr, "merge_state: %s si_syncCookie [%d] %d %s\n", syncrepl.c: fprintf(stderr, "merge_state: %s si_cookieState [%d] %d %s\n", ``` When the man page says "debug messages", it's talking about the messages printed to stderr. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #16 from Shawn McKinney <smckinney(a)symas.com&gt; --- (In reply to Howard Chu from comment #15) Ha, exactly, stop the madness ;-P But, seriously, this is indicative of the confusion that has already been pointed out. OK, good. Clarity has been achieved, and confirms my observations of loglevel, thank you. Got it. and so should converted to use the macro, right? (Admittedly low priority) So, this means we now have two mechanisms that do the same thing. To prevent (the terminology) confusion, the old mechanism, debuglevel, should be deprecated IMO. But, that's besides the point (documentation), and also low priority. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #18 from Shawn McKinney <smckinney(a)symas.com&gt; --- (In reply to Howard Chu from comment #17) How are they different? I'm not talking about how they were implemented, obviously. We're discussing their behavior, i.e. does one replace the other from the user's perspective. loglevel ``` loglevel <integer> [...] Specify the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). They must be considered subsystems rather than increasingly verbose log levels. Some messages with higher priority are logged regardless of the configured loglevel as soon as any logging is configured. Log levels are additive, and available levels are: 1 (0x1 trace) trace function calls 2 (0x2 packets) debug packet handling 4 (0x4 args) heavy trace debugging (function args) 8 (0x8 conns) connection management 16 (0x10 BER) print out packets sent and received 32 (0x20 filter) search filter processing 64 (0x40 config) configuration file processing 128 (0x80 ACL) access control list processing 256 (0x100 stats) connections, LDAP operations, results (recommended) 512 (0x200 stats2) stats2 log entries sent 1024 (0x400 shell) print communication with shell backends 2048 (0x800 parse) entry parsing 16384 (0x4000 sync) LDAPSync replication 32768 (0x8000 none) only messages that get logged whatever ``` debuglevel ``` # /opt/symas/lib/slapd -d ? Installed log subsystems: Any (-1, 0xffffffff) Trace (1, 0x1) Packets (2, 0x2) Args (4, 0x4) Conns (8, 0x8) BER (16, 0x10) Filter (32, 0x20) Config (64, 0x40) ACL (128, 0x80) Stats (256, 0x100) Stats2 (512, 0x200) Shell (1024, 0x400) Parse (2048, 0x800) Sync (16384, 0x4000) None (32768, 0x8000) ``` I did find this in slapd(8), under -d ``` Remember that if you turn on packet logging, packets containing bind passwords will be output, so if you redirect the log to a logfile, that file should be read-protected. ``` I can infer this perhaps means given the same level setting for each, a different content will be output. But this isn't spelled out explicitly, FWICT. Yes, of course the two worked differently prior to 2.6, but we're not considering those differences here. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #20 from Howard Chu <hyc(a)openldap.org&gt; --- (In reply to Shawn McKinney from comment #19) If the logfile_only directive is not used, there is no difference to previous behavior. loglevel controls output to syslog. debug level controls output to stderr. That is how it has always worked, and how it continues to work. If you define a logfile and set logfile_only, then there's effectively no difference, and all output goes only to the logfile, and nowhere else. Is it really so hard to understand that "logfile_only" means to only send output to the logfile? -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #22 from Shawn McKinney <smckinney(a)symas.com&gt; --- (In reply to Shawn McKinney from comment #21) Correction, per slapd-config.5 "Note that the packets, BER, and parse levels are only available as debug output on stderr, and are not sent to syslog." A bit confusing. Since they're listed here: ``` loglevel <integer> [...] 2 (0x2 packets) debug packet handling 16 (0x10 BER) print out packets sent and received 2048 (0x800 parse) entry parsing ``` Trying to figure out how to get these into the logfile using loglevel settings. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 --- Comment #24 from Howard Chu <hyc(a)openldap.org&gt; --- Reiterating for newer audiences: the Admin Guide is only a guide, it is not intended to be an exhaustive reference. That's what manpages are for. There is no need for every possible option to be documented in the Guide; that would just be redundant work. As long as all features are documented in manpages that's sufficient; the Guide can be an overview but at all times, admins must refer to the manpages to get full details. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9726 Quanah Gibson-Mount <quanah(a)openldap.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.3 |2.6.4 -- You are receiving this mail because: You are on the CC list for the issue.