Difference between revisions of "Talk:Projects/Trace logging"

Revision as of 20:47, 8 September 2009

Hello,

Regarding the requirements:

>>It is sufficient to be able to be able to log to a file specified by an environment variable.

Good. We run multiple processes interfacing to the krb5 library, we'll want to ensure each process can write to a unique file.

>>It is important that it be possible to enable trace logging in a standard build, such as the >>one shipped by the operating system vendor, because it is generally not possible to substitute >>specially compiled code in a customer deployment.

Yes. We'd need the ability to enable it, get the data we need, then disable it.

>>There are four basic possibilities here: >> >>4. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.

I like #4. We need the flexibility to be able to selectively log so we can pin-point the problem area and get a problem resolved without having to troll through too many gigs of data.

>>APIs could be provided to turn tracing on and off, or direct different contexts to >>different files. (However, API control of tracing is not a requirement.)

this will be hard to work with as we'd need to build some interface to the process that links and uses the krb library to enable/disable logging. would it be possible to do this by writing something in krb5.conf, which seems to get read quite a bit by the library already? or, perhaps by testing presence of a file, i.e., /etc/krb5_logging.conf and if present, reading/processing it? I agree, from a performance point of view, an API is the way to go; implementation wise to enable, it is harder, but not impossible.

-jc