CUPS in RHEL may not print second file in a multi-file print job

Solution Unverified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 6
  • cups-1.4.2.50.el6_5 or earlier

Issue

  • When printing multiple files (with different file types, PDF and TIFF) using a command line, the first file type will print and the second file will print if it is the same file type. If the second file is a different file type than the first file, the second file will not print.

  • When CUPS transfers a multi-job file from one system to another via IPP and the files have different content types, the IPP backend doesn't properly set the document-format option when it sends the document.

  • A CUPS server receiving a file for printing from another CUPS server won't create the proper filter chain for anything but the first file. This becomes evident where a CUPS client is using BrowsePoll and sending print job to a CUPS server that is sharing it's printers and the client sends a print job containing files of different types. Only the first file is printed.

  • I'm seeing an "Empty print file!" messsage in my error_log. What's wrong?

Resolution

Update CUPS to the latest version avalailable for Red Hat Enterprise Linux 6 (cups-1.4.2-50.el6_4.5 or later). See RHBA-2013:1163-1 for additional information.

Root Cause

When CUPS transfers a multi-job file from one system to another via IPP and the files have different content types, the IPP backend doesn't properly set the document-format option when it sends the document. The document-format sent for all files is that of the first file in the job. This occurs because the IPP backend gets a list of files to transfer in argv[6], argv[7], etc., but only one CONTENT_TYPE environment variable is used, which the scheduler uses to set the MIME type of the first file in the job. The IPP backend in turn uses the single CONTENT_TYPE value to set the document-format option of each file when it sends them to the remote server.

Diagnostic Steps

After enabling debug logging as described in "How to enable and capture CUPS debugging logs", you may see messages like the following in /var/log/cups/error_log in the client:

I [06/Jun/2013:14:28:38 -0700] [Job 12] Queued on "printer" by "user".
I [06/Jun/2013:14:28:39 -0700] [Job 12] File of type application/pdf queued by "user".
I [06/Jun/2013:14:28:39 -0700] [Job 12] File of type image/tiff queued by "user".
D [06/Jun/2013:14:30:40 -0700] [Job 12] Sending job to queue tagged as raw...
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[0]="printer"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[1]="12"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[2]="user"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[3]="01-k20a013d492f66f30ZZZ-CoverPage.pdf"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[4]="1"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[5]="job-originating-user-name=user [...snipped for brevity]"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[6]="/var/spool/cups/d00012-001"
D [06/Jun/2013:14:30:40 -0700] [Job 12] argv[7]="/var/spool/cups/d00012-002"
D [06/Jun/2013:14:30:40 -0700] [Job 12] envp[21]="CONTENT_TYPE=application/pdf"
I [06/Jun/2013:14:30:40 -0700] [Job 12] Started backend /usr/lib/cups/backend/ipp (PID 12227)
D [06/Jun/2013:14:30:40 -0700] [Job 12] 2 files to send in job...
D [06/Jun/2013:14:30:40 -0700] [Job 12] Connecting to 10.1.2.3:631
D [06/Jun/2013:14:30:40 -0700] [Job 12] Connected to 10.14.16.161:631 (IPv4)...
D [06/Jun/2013:14:30:40 -0700] [Job 12] printer-uri = "ipp://10.1.2.3:631/printers/printer"
D [06/Jun/2013:14:30:40 -0700] [Job 12] requesting-user-name = "user"
D [06/Jun/2013:14:30:40 -0700] [Job 12] job-name = "page.pdf"
N [06/Jun/2013:14:30:40 -0700] [Job 12] Print file accepted - job ID 6.
I [06/Jun/2013:14:30:40 -0700] [Job 12] Waiting for job to complete...

And on the /var/log/cups/error_log on the CUPS server, you may see:

I [06/Jun/2013:14:30:41 -0700] [Job 6] Queued on "printer" by "user".
I [06/Jun/2013:14:30:41 -0700] [Job 6] File of type application/pdf queued by "user".
I [06/Jun/2013:14:30:41 -0700] [Job 6] File of type application/pdf queued by "user".

So although there were two files sent by the client, one PDF and one TIFF, the server believes that they are both PDF files.

Depending on the types of files being sent, you may also see messages like the following on the CUPS server:

I [16/May/2013:11:05:09 -0500] [Job 113] Started filter /usr/lib/cups/filter/pdftops (PID 29871)
D [16/May/2013:11:05:09 -0500] [Job 113] Started filter pdftops (PID 29872)
D [16/May/2013:11:05:09 -0500] [Job 113] Started filter pstops (PID 29873)
D [16/May/2013:11:05:09 -0500] [Job 113] Error: May not be a PDF file (continuing anyway)
D [16/May/2013:11:05:09 -0500] [Job 113] Error: PDF file is damaged - attempting to reconstruct xref table...
D [16/May/2013:11:05:09 -0500] [Job 113] Error: Couldn't find trailer dictionary
D [16/May/2013:11:05:09 -0500] [Job 113] Error: Couldn't read xref table
D [16/May/2013:11:05:09 -0500] [Job 113] PID 29872 (pdftops) stopped with status 1!
E [16/May/2013:11:05:09 -0500] [Job 113] Empty print file!
D [16/May/2013:11:05:09 -0500] [Job 113] PID 29873 (pstops) stopped with status 1!
E [16/May/2013:11:05:11 -0500] [Job 113] Job stopped due to filter errors; please consult the error_log file for details.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.