logging

Richard Marko rmarko at redhat.com
Tue Sep 3 14:30:01 UTC 2013


On 09/03/2013 08:26 AM, Jiri Moskovcak wrote:
> On 09/02/2013 01:21 PM, Richard Marko wrote:
>> On 09/02/2013 01:01 PM, Jiri Moskovcak wrote:
>>> On 09/02/2013 11:26 AM, Richard Marko wrote:
>>>> +        sys.stderr.write("/etc/kdump.conf not readable, using "
>>>> +                         "default path '%s'\n" % dump_path)
>>>> +        return dump_path
>>>> +
>>>
>>> - please factor out the logging functions from
>>> abrt-action-analyze-core script and use it in both scripts
>>> - they also exists in the reportclient module in libreport, so maybe
>>> you can use them instead of creating just another abrt module
>>
>> I've had a version which used syslog module instead of writing to stderr
>> but I've replaced it as the rest of the code uses stderr and I'll
>> be fixing this everywhere due to rhbz#1001139.
>>
>> The question is where should these scripts log by default - to stderr or
>> to syslog?
>>
>> I think using syslog is better than current situation.
>>
>
> - It depends on availability of tty, if tty is available (means the
> app were started from the terminal) I would log to stderr, otherwise
> to syslog
> - but please make sure that only really important problems are written
> to syslog if the verbosity == 0

Should be possible to implement with isatty. I was thinking about
following: logging functions factored out would
 - log to stderr if stderr is real tty
 - log to syslog if running as daemon
 - [later] log to journal via it's native api


Regarding verbosity, I would solve this with proper log levels
(log_debug, log_warn, log_error) which would pass level to
syslog/journal where filtering is available while using verbosity when
stderr is used.

-- 
Richard Marko



More information about the Crash-catcher mailing list