[cups.general] Debugging the filter chain?

[Helge Blischke]

William Pietri wrote:

> Thanks for the reply, Johannes.
> 
> On 10/20/2010 01:04 AM, Johannes Meixner wrote:
>> Hello,
>>
>> On Oct 19 17:26 William Pietri wrote (shortened):
>>    
>>> Since I'm pretty ignorant of CUPS, I don't know how much sense these
>>> suggestions make, but if I could wave a magic wand, these would have
>>> been nice:
>>>
>>>   1. In debug logging, printing the full arguments of all filters
>>>   called.
>>>      
>> See "man 7 filter" and "man 7 backend":
>> All filters and the backend are called with the same command line
>> arguments which are logged as "argv[0]"..."argv[6]" and with the
>> same environment variables which are logged as "envp[0]"...
>>    
> 
> Ah yes. I saw that in the output, but didn't realize the connection.
> Perhaps all of that could be preceded by some line that makes it clear
> it goes with the filters? E.g.:
> 
>     Starting 5 filters and 1 backend with the following arguments:
> 
> 
>>>   2. In regular logging, calling out sending a zero-byte payload to the
>>>      printer as an error.
>>>   3. The ability to get a little information on what's getting passed
>>>      between filters, so that I can tell where the failure is. E.g.,
>>>      logging how many bytes each filter takes in and puts out.
>>>   4. Getting dumps of the contents at each stage in the filter chain,
>>>      so I could inspect things.
>>>      
>> What the cupsd does when it runs the filters is that it forks
>> for each filter and for the backend a separated process where
>> - only the first filter gets its input as file named via argv[6]
>> - all others get the input via stdin via pipe from the predecessor
>> - only the backend sends its output directly to its recipient (printer)
>> - all others provide the output via stdout to a pipe to the successor
>> - all their stderr go to the cupsd which forwards it to the log
>>
>> Therefore it is not possible for the cupsd to inspect the data
>> which is forwarded via pipes from one filter to the next
>> (or to the backend) so that the cupsd cannot log how many bytes
>> each filter takes in and puts out or even dump the contents.
>> This would require that also all data of all filters is sent
>> via the cupsd which results probably a huge loss of performance
>> (a few bytes stderr but megabytes up to gigabytes of payload).
>>    
> 
> Ok. That makes sense. I'd still appreciate having the "Sending data file
> (0 bytes)" bit called out as an error rather than a debug message,
> unless there's some case where a zero-byte lpd payload makes sense; that
> would have gotten me on track sooner.
> 
> And although those other items clearly don't make sense in general,
> could they make sense as part of some debug mode? Had I been stuck for
> long, I would have started inserting fake filters to nab the data. I
> don't know how often people end up having to debug the filter chain, so
> maybe my use case isn't important enough to worry about. But if it is, a
> config option like dump_all_filter_steps might be handy.
> 
> Either way, it's not a big deal for me; I just am trying to contribute
> what I little I can: feedback.
> 
> William

Did you look at the cupsfilter utility? It permits testing a filter chain as 
set up by the mime files and the PPD offline (i. e. outside of cupsd) and 
spits out all the debug messages.

Helge