CUPS: lp command only prints last file

Question

I try to print two files from the command line thus:

$ lp alpha.txt beta.txt

The lpq command gives this output:

$ lpq
HP_OfficeJet_Pro_6970_7BE7A4 is ready
Rank    Owner   Job     File(s)                         Total Size
1st     claus   56      alpha.txt                       2048 bytes

Here, it mentions only the file alpha.txt. However, only the file beta.txt is actually printed. alpha.txt is not printed.

What might be the reason for that?

I'm running Ubuntu 22.04.1 LTS with CUPS 2.4.1.

FURTHER INFORMATION

If I use lp to print more than one file, these messages appear the /var/log/cups/error_log:

W [13/Dec/2022:16:22:19 +0100] [Job 61] /tmp/12345639a6b95: file is damaged
W [13/Dec/2022:16:22:19 +0100] [Job 61] /tmp/12345639a6b95 (offset 14802): xref not found
W [13/Dec/2022:16:22:19 +0100] [Job 61] /tmp/12345639a6b95: Attempting to reconstruct cross-reference table

FURTHER INFORMATION 2

The file name in the log starts with 12345. This neat pattern is a coincidence. Repeated attempts show that the first 5 digits of the filename appear to be the hexadecimal value of the PID of the gstoraster CUPS filter that runs as part of the printing process. So perhaps, the problem lies with that filter.

I made a few tests with multiple files to Boomaga printer driver and I got an Error on 551: Can't read genNum message. You can try to print the files like this: cat alpha.txt beta.txt | lp. — FedKad, Dec 10 '22 at 10:20
@FedKad: Unfortunately, the solution with cat doesn't work if I'm printing a mixture of .txt and .pdf files. Also, I'll have to manually insert page breaks between the files. — oz1cz, Dec 10 '22 at 10:26
Check if you have a shell alias for that command that maybe doesn't properly forward all arguments that it gets to the underlying command. That happened to me more than once. — HuHa, Dec 11 '22 at 01:12
@HuHa: That can't be the problem. As you see, the lpq command lists the file alpha.txt, but beta.txt is the file that's actually printed. So somehow the print system knows about both files. — oz1cz, Dec 11 '22 at 13:22
Could you check which lp and try lp -- alpha.txt beta.txt — user.dz, Dec 13 '22 at 12:51
Please try and see if for f in "alpha.txt" "beta.txt"; do lp "$f"; done makes a difference ... i.e. using the loop to send each file as a separate single argument. — Raffa, Dec 13 '22 at 13:25
@user.dz: which lp prints /usr/bin/lp. Using lp -- alpha.txt beta.txt makes no difference.
@Raffa: Issuing two lp commands causes both files to be printed; and this is, of course, a useful substitute. However, the documentation for lp says that it should be possible to print multiple files using one command, so I wonder why it doesn't work. — oz1cz, Dec 13 '22 at 15:05
It seems that alpha.txt is not really a plain text file and it is damaged … "missing external reference” usually happens with binary files e.g. images … Test with echo "text 1" > file1.txt && echo "text 2" > file2.txt && lp file1.txt file2.txt and see how it goes. — Raffa, Dec 13 '22 at 16:09
@Raffa: alpha.txt is absolutely a plain text file. I created it exactly as you suggest, and a hex dump of the file shows it as entirely a plain text file. Anyway, the error message is not "missing external reference" but "xref not found", which could be an internal reference created by gstoraster, if that is indeed the problem filter, as I suggested in my latest addition to the post. — oz1cz, Dec 13 '22 at 16:32
"xref" is not necessarily "external reference". It can simply mean "cross reference". — oz1cz, Dec 13 '22 at 16:49
Oh, I see … could be corrupted printer/spooler … So probably removing and reinstalling both cups and ghostscript might fix it. — Raffa, Dec 13 '22 at 16:50
@Raffa: I doubt it. I recently reinstalled everything on my computer, and I had the problem both before and after the reinstallation. Anyway, I've discovered that CUPS has a mailing list for this kind of problem. Maybe I should try there. Anyway, thank you for your kind effort. — oz1cz, Dec 13 '22 at 16:53
@oz1cz Please, update this Q&A with more information as it becomes available. Obviously, it looks that there is bug in the lp software. — FedKad, Dec 15 '22 at 10:21
@FedKad: I will. I've asked the same question on a CUPS mailing list, but so far I've had no reply. — oz1cz, Dec 15 '22 at 15:52

score 2 · Accepted Answer · answered Dec 16 '22 at 08:35

Answering my own question:

I posted the question on the CUPS mailing list and got this answer from Helge Blischke:

Well, I do not completely understand what is going on here, but I at least have a hypothesis I’ll try to explain here.

What I’ve learned from your log file is:

— Your printer is set up using an emulation of implicit classes (developed by openprinting to make the functionality of implicit classes implemented in cups 1.x available in cups 2.x) based on the functionality off cups-browsed.

This approach seems - to me at least - rather complicated, and the key feature is that the backend "implicitclass", which is used here, collects all jobs for the printer in question by executing the complete filter chain for each job file.

— This implies e.g. for PDF files (the cups-filter strategy is to convert all files to be printed at least intermediately to PDF using the pdftopdf filter, which - to my experience - appends an additional EOF character (^Z, I think) to each PDF file.

— Somewhere in the filter chain executed by the implicitclass backend the PDFs are processed by routines implemented in the QPDF library, which leads to PDF error messages caused by the intermediate ^Z characters — that is at least what I deduct from the various messages.

As I myself do not use the cups-filters package (even on my Linux box I don’t), I have no chance to digest further into this problem.but I think my thesis cant’t be completely wrong.

So, apparently, it's a rather complicated bug in CUPS, and I'll just have to live with it.

CUPS: lp command only prints last file

1 Answers1