On Mon, 2011-06-20 at 23:03 +0200, Jan Zeleny wrote:
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> On Mon, 2011-06-20 at 21:55 +0200, Jan Zeleny wrote:
> > Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> > > Ok, I'm going to try to summarize the responses from Simo and Jakub,
> > > then hopefully we'll accept them and we can add this information to
> > > coding and contribution guidelines. (I have intentionally broken the
> > > thread).
> > >
> > > I agree with Simo that we should break this into a bitfield. I'm
> > > to suggest that we consider a match of 0x000F to be an error, 0x00F0 to
> > > be informational and 0x0F00 to be developer. This adjusts Simo's
> > > numbers slightly, but it makes a little more room available at each
> > > level in case we want to add a new level in the middle.
> > >
> > > I also think we should change the config file option name to
> > > rather than "debug_mask". I think it's more readable.
> > How would this mask look and work exactly?
> I meant that "debug_level = 9" would become "debug = 0xFF" in
> file (I think allowing it to be set to either hex or decimal is more
> sensible than just decimal)
When discussing this with others, have you considered some kind of pre-defined
constants so the value can be also entered as bit-or of these constants?
That would be really tricky to implement in the config file logic, I
think. If we wanted to do that, I think maybe we'd limit ourselves to
just FOUR constants: FATAL (synonymous with 0x0000 and the default),
ERROR (0x00F0), INFO (0x0FF0) and DEBUG (0xFFF0). (Using Simo's
suggestion in the other email that we reserve the lowest bits for legacy
So the idea would be if debug was passed a number (either in decimal or
hexadecimal) we would use the exact value. If we were passed a string,
if it matches one of the above codes we would set the value as described
> > When we are discussing debug messages, I vaguely recall
that debug level
> > 0 logged only to /var/log/secure and not to /var/log/sssd/*. Is this
> > intended?
> I don't know where you got that idea. I suggested that the DEBUG macro
> should ALSO log to /var/log/messages for all level-0 issues. But they
> should still be in the standard debug logs as well.
I think I once ran into a situation where sssd crashed and there was only very
limited information in /var/log/sssd/* files and it took me a while before I
figured out more information is in /var/log/messages.
Right now I managed to reproduce this behavior by chmod 640
/etc/sssd/sssd.conf, not sure whether the debug code path is the same.
The only time that should ever be possible is if SSSD crashed before we
set the debug_prg_name. If that's the case, syslog is the only way we
can dump out information. (Though perhaps we should consider setting the
debug_prg_name to "sssd" for all services until after init, so we don't
have to worry about these messages.
I consider this a separate issue though (a bug, rather than a discussion
of the log level feature).