On Tue, Feb 04, 2014 at 11:33:19AM +0100, Sumit Bose wrote:
On Fri, Dec 20, 2013 at 05:05:56PM -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> All of these patches require Nikolai's "DEBUG Macro Refactoring v3"
> patches to be applied first.
> Patch 0001: Allow debug_fn to process __FILE__ and __LINE__
> In preparation for enabling journald support for the DEBUG logs, we
> will need to be able to pass in certain additional arguments that will
> be required, specifically the code file and line number.
> We will be able to optionally enable this in the file-based logs as well
> if we so choose, but for right now we will avoid breaking the log
> format on disk.
> Patch 0002: Enable sending structured debug logs to journald
> We are now able to send structured debug logs to journald, tagged with
> the code file, line number and domain that the log pertains to. To
> enable this functionality, SSSD must be configured at build-time with
> - --with-syslog=journald and must be launched without -f/--debug-to-files
> This behavior is nearly identical to how SSSD will function today on a
> systemd-based system if --debug-to-files is disabled, since it will
> redirect stdout and stderr into journald. This patch merely enhances
> the situation to send structured logs instead of simple string messages.
I have to admit that I haven't look into much detail about what journald
is capable of. So there is a fair chance that the following can already
easily solved within journald.
On typical scenario when a user hits an issue is that we ask to increase
the debug level and collect the logs which are generated when
reproducing the issue. With structured logs it is easy to get the
specific logs out of journald but I wonder if we want to write
everything into journald in the first place and fill its storage with
one-time debug data?
I was thinking if we might want to introduce a new option which gives
some upper value for log levels which should go to journald. Then every
message up to this level will always go to journald. If the debug_level
is higher then this value debug files with all messages are created as
well. This way we still have all error message in the journal but keep
it free of debug messages.
An alternative, if journald supports it, would be to provide special
config options to instruct journald to store messages with a high
debug_level to a short term storage where they can easily be deleted
without removing other messages as well.
I was playing with journald some more this morning and I haven't found
a way to solve your concerns easily. As far as I could see it is only
possible to redirect messages to persistent or volatile storage globally,
not per-unit. But maybe I missed something.
Luckily, the journald has an upper cap on the size the journal takes
So far the easiest way I found was disabling the logging with sss_debuglevel
after the debugging is done. For now, it's not a big deal as the journal is
not enabled by default, but we should think about this issue again if we
wanted to make journald the default.