RE: logging enhancements, take 2

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

First, I think we should focus on getting the subsys/level logging
implemented so we can sort out the many issues regarding which
subsys and which level to use.  So, I rather defer discussion
regarding new features.

However, I will make a few comments on the addition of 1) timestamps,
2) thread ids, and 3) connection id.

I see little reason for the caller or log routine itself to add
timestamps.  Adding of timestamps can easily be done externally
(via syslogd or a timestamp program).

I see thread ids as something that is generally useful for threaded
applications (slapd, slurpd).  However, it is inappropriate for
an lutil routine to make any thread call.  So, the id needs to be
passed in.  As id forms differ from thread system to thread system,
likely would need a routine to produce a string which could be
passed in on each call.  This can be easily added later on.

I see no reason to record connection id's on a per log message
basis.  The connection id is inferred by (per thread) sequence
of messages.  Note that each thread entry point should
already be logging the connection id.

Kurt

At 02:22 PM 10/9/00 -0400, Gary Williams wrote:
>OK, consider me off and running on this.  Someone asked that
>thread number be put on log lines.  In the slapd logging, I
>would also like to see the connection number added.  The output
>should look like:
>
>date                   thread     cnxn     output
>20001009:14:20:24.392 [t:_thrd_] [c:_cnx_] Debug output from slapd code.
>
>This information doesn't apply to client logging (usually).  Should
>the slapd logging macro require these, and the logging
>function put them in the output string, or just as a convention,
>request that calls to the logging routines include them?
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>> Sent: Monday, October 09, 2000 1:56 PM
>> To: Gary Williams
>> Cc: 'openldap-devel@openldap.org'
>> Subject: Re: logging enhancements, take 2
>> 
>> 
>> At 01:02 PM 10/9/00 -0400, Gary Williams wrote:
>> >Here's what I have for libldap:
>> >
>> >The following is added to print.c.  Similar changes would be 
>> made in modules
>> >for the other libraries (liblber, libavl, etc.)  A static 
>> variable holding the
>> >address of an external logging routine, and functions that 
>> can set and get the
>> >address.  The debugging macro would then check the external 
>> function and use it
>> >if it's been set, otherwise use the existing logging routine.
>> 
>> I suggest a slight twist...
>> 
>> It would be nice if could always use the macro:
>>         LDAP_LOG( subsys, level, fmt, ...)  /* preferred */
>> or
>>         LDAP_LOG(( subsys, level, fmt, ...))
>> 
>> no matter which subsys we were in... but than inside each
>> subsystem requiring independent logging (-lldap -llber),
>> this would use an internal such as ber_int_logger() instead of
>> the full lutil logger.  OpenLDAP applications would call call
>> lutil_log_initialize() to (amongst other things) install the
>> full logger, lutil_int_logger().
>> 
>> It's best to use a function to do the switching (using an
>> internal hook), then to expose the hook, hence, I suggest:
>>         #define LDAP_LOG ber_pvt_logger  /* preferred */
>> or
>>         #define LDAP_LOG(x) ( ber_pvt_logger x )
>> 
>> and let ber_pvt_logger() determine whether or not to use
>> ber_int_logger() or lutil_int_logger() (as installed via the hook).
>> 
>> As far as the hook...
>> >static void (*ldap_logProc) LDAP_P(( char *subsys, int 
>> level, char *fmt, ... ));
>> 
>> That's reasonable prototype, but the hook needs to be -llber and
>> should be named per conventions, i.e:
>>   static void (*ber_int_log_proc)( const char *subsys, int level,
>>         const char *fmt, ... )
>> 
>> And should be set using:
>>   ber_set_option( NULL, LBER_OPT_LOG_PROC, (void*) lutil_int_logger )
>> 
>> from lutil_log_initialize()
>> 
>> [contrary to what I might have said previously] I would suggest that
>> the default logger (lber_int_logger) use a global log level (as this
>> is simpler to implement) which could be accessed via either
>> LBER_OPT_DEBUG or LDAP_OPT_DEBUG (LDAP_OPT_DEBUG would set 
>> LBER_OPT_DEBUG).
>> This means that a non-OpenLDAP application setting TRACE gets TRACE
>> across all subsystems (-lldap and -llber).  I don't have much problem
>> with this.
>> 
>> >If this is acceptable, I'll proceed putting it in all the 
>> libraries and updating the
>> >configuration routines and command lines to accept logging 
>> configuration. 
>> 
>> For command line, reuse -d.
>>