[cups] debugging file auto-typing

[Tim Mooney]

In regard to: Re: [cups] debugging file auto-typing, Zdenek Dohnal said (at...:

Thanks for the response, Zdenek.

> I would look into /var/spool/cups for files starting with 'd' and check
> their file type. It will get you initial idea what filetype goes to CUPS.

That I'm familiar with.  I've saved the data file for one of the problem
print jobs in question.

These jobs are coming from a print rendering service for mobile devices,
so the job has already had format conversion done by that service.  My
expectation is that the auto-typing code should have both

 	application/pdf
 	application/vnd.cups-raw

as matching file types (pdf because the document extension is .pdf).
In other cases when our CUPS print server receives pre-rendered PDFs,
it always (correctly) chooses application/vnd.cups-raw as the type.
In this case it's choosing application/pdf and then trying to do
format conversion again.  pdftops is then failing on the file, since
the format is no longer PDF.

I'm just trying to determine why these pre-rendered PDFs are
getting type application/pdf when other pre-rendered PDFs get
application/vnd.cups-raw.  I was initially suspicious that the size of
the "header" in the document was causing the '@PJL ENTER LANGUAGE=PCLXL'
to be outside of the 0,4096 range for the contains() for
application/vnd.cups-raw, but I don't think that's it.

> Then the function, which does recognizing mime types, is mimeFileType()
> from scheduler/type.c. I would recommend checking error_log with debug2
> logging turned on or tracking the process with gdb.

Thanks, that's very helpful!  I had run 'cupsfilter' with the data file
in question under ltrace last night and noted a bunch of mime-related calls:

mimeLoadTypes(0, 0x7fffca745420, 0x7fffca745434, 0x7f754555e58e, 5) = 0x7f754731b400
mimeLoadTypes(0x7f754731b400, 0x7f7547311e80, 0, 0, 0x7f75473133f0) = 0x7f754731b400
mimeLoadFilters(0x7f754731b400, 0x7fffca745420, 0x7f7547311ea0, 0, 0x7f7547312e40) = 0x7f754731b400
mimeLoadFilters(0x7f754731b400, 0x7f7547311e80, 0x7f7547311ea0, 0, 0) = 0x7f754731b400
mimeType(0x7f754731b400, 0x7f754555e5bb, 0x7f754555e5a7, 0, 0) = 0x7f7547323180
mimeFileType(0x7f754731b400, 0x7fffca7476a1, 0x7fffca7476a1, 0x7fffca744c1c, 0) = 0x7f754731d5b0
sscanf(0x7fffca747695, 0x7f754555e4ad, 0x7fffca745920, 0x7fffca745820, 4081) = 2
strcasecmp("printer", "printer")                 = 0
mimeFilter(0x7f754731b400, 0x7f754731d5b0, 0x7f7547323180, 0x7fffca744c18, 255) = 0x7f754731cd20

but until your email I wasn't certain which of them I needed to start
with.  Now I know where I should begin my debugging.

We already run the server with debug enabled, but I'll also keep debug2
in mind too, if gdb on cupsfilter isn't getting me what I need.

Thanks much for your response!

Tim

> On 2/14/19 2:03 AM, Tim Mooney wrote:
>>
>> All-
>>
>> Is there a recommended practice for debugging why CUPS chooses a certain
>> mime type when auto-typing a print job?
>>
>> I know I can use local.types and my own types with priority() to force
>> CUPS to prefer a particular type, but what I'm trying to determine is
>> which types are coming out of the process as candidates.
>>
>> Is my best bet something like installing the debug symbols for
>> 'cupsfilter' and stepping through what its doing with a debugger?
>>
>> If it makes a difference, this is for CUPS 1.4.2 on RHEL 6.10.  In
>> addition, this is for a central CUPS print server that is receiving
>> print jobs from a variety of client systems.
>>
>> Thanks,
>>
>> Tim
>
>

-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164