[cups.general] Debugging the filter chain?

[William Pietri]

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