Printer idle and job not visible even though it is printing

[shunkica]

When printing to a Ricoh Pro 8320 from a linux server running cups 2.2.6 using the OpenPrinting Ricoh PS PPD file, as soon as the job is submitted to the printer it dissapears from lpstat -o and lpstat -p shows the printer as idle, even though the printer is still printing.

I have a older server running cups 1.4.2, and on that server i can see the job as long as it is printing and there is even a page_log for the job.

Both servers are connected to the printer using the socket:// protocol.

This is the output of lpoptions:

copies=1 device-uri=socket://ricoh8320:9100 finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=1732047506 marker-colors=#000000,#000000,none marker-levels=50,100,0 marker-names='Toner\ Cartridge\ (Left),Toner\ Cartridge\ (Right),Waste\ Toner' marker-types=toner,toner,waste-toner number-up=1 printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info=RicohPS printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location printer-make-and-model='Ricoh Pro 8320 PS' printer-state=3 printer-state-change-time=1732047506 printer-state-reasons=none printer-type=8434164 printer-uri-supported=ipp://localhost/printers/RicohPS

I have tried using ipp with this printer but when I send large PDF files (hundreds or thousands of pages) it just errors out after printing a couple of hundred pages.

[zdohnal]

Can you try the latest upstream versions? Otherwise it would be great if you contacted your distro support, since version 2.2.6 is about 6 years old.
From what I see there were some changes in socket backend between 2.2.6 and 1.4.2, but the main waiting loop after print file is sent stayed the same (socket backend is in loop till printer sends data via backchannel - breaks from it once number of read bytes is 0 or less).

I have HP Color LaserJet MFP M277 which behaves the same in 2.4.11 - the job finishes in cupsd because printer does not send anything via backchannel, which we takes as indication the printer is done. IMO I can't do much about it (I've even tried to remove shutdown() of the socket before wait_bc(), but the printer goes silent either way).

You can check investigate debug2 logs between versions and see what changed and how the printer behaved with older CUPS.

Regarding IPP you can investigate what output actually goes to the printer - checking debug logs, network traffic etc.

[shunkica]

Can you try the latest upstream versions?

It's an el8 system and that is the latest version of cups that ships with it. I don't feel comfortable building from source since it's a production system. The older server where it works as it should is a el6 i686 system.

I have HP Color LaserJet MFP M277 which behaves the same in 2.4.11 - the job finishes in cupsd because printer does not send anything via backchannel, which we takes as indication the printer is done. IMO I can't do much about it (I've even tried to remove shutdown() of the socket before wait_bc(), but the printer goes silent either way).

I have read some documentation and found that there exists a waiteof option when using raw socket printing. Maybe setting this explicitly to true could work?
Also after posting this I have installed foomatic-rip on the el8 system since I see it is used in the ps filter of the ppd file, but I have not printed anything since then. Maybe that has something to do with it ( I don't really understand what foomatic does and haven't had the time to research it ).

You can check investigate debug2 logs between versions and see what changed and how the printer behaved with older CUPS.

Regarding IPP you can investigate what output actually goes to the printer - checking debug logs, network traffic etc.

This is something i must find time for to delve deeper into.

[zdohnal]

Can you try the latest upstream versions?

It's an el8 system and that is the latest version of cups that ships with it. I don't feel comfortable building from source since it's a production system. The older server where it works as it should is a el6 i686 system.

So it would be great if you contacted your distribution support - they can help you more if requested.

I have HP Color LaserJet MFP M277 which behaves the same in 2.4.11 - the job finishes in cupsd because printer does not send anything via backchannel, which we takes as indication the printer is done. IMO I can't do much about it (I've even tried to remove shutdown() of the socket before wait_bc(), but the printer goes silent either way).

I have read some documentation and found that there exists a waiteof option when using raw socket printing. Maybe setting this explicitly to true could work?

This is turned on by default, but you haven't provided any debug logs, so I don't know if you don't turn off it in URI of printer.
Either way, the waiting loop I wrote above happens when waiteof is turned on.

Also after posting this I have installed foomatic-rip on the el8 system since I see it is used in the ps filter of the ppd file, but I have not printed anything since then. Maybe that has something to do with it ( I don't really understand what foomatic does and haven't had the time to research it ).

IMO it won't influence whether the backend ends before the printer is done, unless it would slow down the filtering, so the backend would be sending data for longer time than before (AFAIK foomatic-rip does the final filtering for drivers which uses it, so if it worked for you without it, the printer accepts the document format which goes to foomatic-rip as well), but you check it.

You can check investigate debug2 logs between versions and see what changed and how the printer behaved with older CUPS.

Regarding IPP you can investigate what output actually goes to the printer - checking debug logs, network traffic etc.

This is something i must find time for to delve deeper into.

[shunkica]

I have printed 10 pages of a PDF document and 10 pages of a PS document with cups debugging enabled and this is the cups debug log: https://gist.github.com/shunkica/dcf1f414a9990650c0deee411c997347

[zdohnal]

There is no response from the printer by backchannel according the logs. When I used strace on the backend, I see the file descriptor matching for connection with printer reports there are data for reading, but if we read from descriptor, there is no data read.

You can check your backend by strace too, if you see something similar.