[cups.general] [Fwd: [Printing-user-general]Whyhasnothingchanged?]

[Helge Blischke]

Michael Sweet wrote:
> Johannes Meixner wrote:
> 
>> Hello,
>>
>> On Aug 1 07:08 Michael Sweet wrote (shortened):
>>
>>> ... just redirecting
>>> the filter's stderr to the log file would lose the time stamp and
>>> log level info
>>
>>
>> I understand that no time stamp could be added but for per job
>> logs they are not very important because the messages will
>> appear in chronological order (as sent by the filters/backend).
> 
> 
> Timing information is often very important in tracking down
> printing errors.
> 
>> But I do not understand that there is no log level info because
>> wouldn't the filters/backend have to use log level prefixes?
> 
> 
> It is optional - without a prefix, a line is treated as "DEBUG".
> 
> Also, we have to parse out STATE, ATTR, and PAGE messages for
> use by the scheduler...
> 
>> I assume there are other problems why just redirecting
>> the filter's stderr to the log file is not possible:
>> The prefixes ATTR, PAGE, and STATE are no longer recognized
>> at all by the scheduler and the LogLevel directive would become
>> useless because the log file would always log anything from stderr.
> 
> 
> We'd pass the LogLevel to the helper program (along with any other
> into that was required), and probably have the helper pass the
> non-log messages up to cupsd for processing.
> 
>>>> I assume that when only INFO, WARN, and ERROR messages are stored,
>>>> it should avoid flooding the files with tons of debug messages.
>>>
>>> Without the debug messages, the log file would be pretty much useless
>>> for tracking down problems... :)
>>
>>
>> Yes.
>> But the intention of my feature request was not for real hard
>> debugging because this requires an experienced user and for
>> experienced users the error_log is o.k.
>> Instead my intention was better info for the user why this or that
>> printout fails.
> 
> 
> Well, with the LogLevel set to "info", you probably won't get any
> messages from the filters that will explain why the printout failed...
> 

Wouldn't it be sufficient to tag the (*all*) messages written to the
log file with the job number or, if it is not job-related, with some component
tag, and provide a sort of "log-digest" utility which can extract the
messages by tag?

Helge


-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de