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

Michael Sweet mike at easysw.com
Tue Aug 1 08:01:33 PDT 2006


Helge Blischke wrote:
> 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?

Well, we already do this in the error_log file ("[Job NNN] message"),
but this particular issue is that most of the useful debugging
information is found by setting the log level to - you guessed it -
"debug"!  :P

So we're back to determining the functionality that is required
for per-printer and/or per-job log files, making sure that we
retain support for the page_log and the other non-log messages a
filter/backend might produce.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com




More information about the cups mailing list