Trace logging project

Nicolas Williams Nicolas.Williams at
Mon Sep 14 16:03:28 EDT 2009

On Mon, Sep 14, 2009 at 03:32:51PM -0400, Greg Hudson wrote:
> As noted in the project page, the primary use case here is to help
> experienced users (such as support staff) diagnose configuration
> problems, not to aid programmers in debugging.  So, for instance, it's
> important to know what preauth systems kinit tried to use or what KDC
> was contacted for a TGS request.  Information at the level of function
> calls is not important to this use case.


> > Also, I think you should consider a DTrace USDT provider.
> I will have to read up on this.

Please do.  I think it's likely that you could have one set of macros
that uses your trace facility in the [build-time] absence of DTrace, or
which expand into DTrace USDT probe sites in the presence of DTrace.

(I bet we'd be interested in a krb5 DTrace USDT provider, and perhaps so
would Apple engineers.  But if the macros are sufficiently general I
think Linux and others could benefit as well.  I've not looked recently
at USDT provider construction, so I don't know whether this is

> > Context initialization is interesting, and should be traceable without a
> > context, for obvious reasons.
> If the simple fact of context initialization is interesting, then that
> can be traced just before krb5_init_context returns.
> A more interesting question is whether we should trace profile reads,
> since those are done with a profile handle instead of a krb5 context.
> I'm not sure if those count as interesting events, though.

Context initialization _failures_ are interesting.  Context init success
is utterly uninteresting, though as you say, what config files are read
is potentially interesting.

> > > [...] littering the code base with tracing calls.
> > 
> > Ugh.  [...] I'd hate to see the
> > code littered with trace macros/function calls in all function entries,
> > before gotos, before returns.
> I think my use of the word "littering" connoted more than I really
> meant.

I hope so.  Solaris Kerberos used to be so-littered, and it was an eye

Incidentally, I've built DTrace scripts, using the PID provider, to get
at cleartext from deep in libkrb5 that normally there's no way to get
at.  It's certainly feasible to do this, and perhaps we ought to keep an
archive of useful scripts for tracing MIT Kerberos.


More information about the krbdev mailing list