4

I am communicating with CUPS using IPP protocol. I have all drivers for my printers installed in CUPS (using .ppd file) and printers got latest firmware.

When I query a job which a printer printing right now it says that the job's state is 'complete' before the printer even finish printing. It seems that the CUPS marks the job as 'complete' when it finish 'uploading' the file.

I would not expect this behaviour and I basically need to know when exactly the printer printed last paper for a job. The code looks as follow. The self.printer().ippPrinter() is an instance of node-ipp and it points to a printer. To read the the state of the job I am using attribute 'job-state'.

var msg = {
  "operation-attributes-tag": {
    'job-id': id
  }
};

self.printer().ippPrinter().execute("Get-Job-Attributes", msg, function(err, res){
  var attributes = res['job-attributes-tag'];

  self.setAttributes = attributes;
  callback.call(self, attributes);
});

Does anyone know why I am having this issue or .. how to make it working? Thank you!

IPP Nerd
  • 992
  • 9
  • 25
Jakub
  • 1,037
  • 8
  • 21

2 Answers2

4

CUPS can only forward job-states received from the printer. A lot of printer drivers and protocols work like 'fire and forget'.

Usually IPP printers allow CUPS and other clients to monitor the current job-state until it's finished/printed. Some manufacturers don't implement IPP properly and classify submitted jobs as printed - even if the printer has a paper jam!

Conclusion:

If your printer does not fully support IPP you probably won't be able to check for 'printed successfully'.

RFC 8011 5.3.7.1

If the implementation is a gateway to a printing system that never provides detailed status about the Print Job, the implementation MAY set the IPP Job’s state to ’completed’, provided that it also sets the ’queued-in-device’ value in the Job’s "job-state-reasons" attribute

IPP Nerd
  • 992
  • 9
  • 25
  • Peter, I'm ending with completed jobs when the printer has not printed even a single page (but it has received all the input data and I can later ask the printer to continue with the job manually). I guess that the [backend](https://www.cups.org/doc/man-backend.html) that talks the printer protocol (i.e. AppSocket for HP) can only do the 'fire and forget' that you mention and CUPS can only mark that job as completed. For lpd and socket protocols, there is a chance that changing the driver this situation could be improved? A different driver could install a better backend? Thanks. – gabrielgiussi Jul 18 '17 at 21:01
  • I am not aware that lpd or socket protocols offer better ways to monitor the jobs. In any case the printer would have to support this monitoring as well. From my experience ipp offers more options but that might be a biased opinion :-) – IPP Nerd Nov 30 '17 at 23:27
1

@Jakub, you may well be communicating with CUPS using IPP... But are you sure that CUPS is communicating with the print device via IPP?

You can check this by running

 lpstat -h cupsservername -v

This should return the device URI assigned to each print queue, which CUPS uses to address the actual printing device:

  • If that URI does contain ipp://, ipps://, http:// or https:// CUPS indeed talks IPP to the print device and you should be able to get actually correct status messages.

  • But if you see socket:// then CUPS is configured to use the AppSocket method (sometimes also called 'HP Jet Direct' or 'IP Direct Printing') to forward jobs. This is a "fire and forget" protocol. Basically it is the same as if you did run netcat print-device 9100 < myprintfile to shovel the printable data to port 9100 of the printer. The CUPS socket backend handling this spooling to the printer will not get any other acknoledgement from the printer than what TCP/IP provides confirming that the last packet was transfered. Hence it has to close down its process and report to the CUPS daemon successful-ok, even if the printer is still busy spitting out lots paper and will maybe never complete the full job because it runs into a paper jam...

  • If you see lpd:// the situation is similar (but uses port 515).

You may have success with a full status reporting by switching the CUPS-to-printdevice path from AppSocket or LPD to IPP like so:

 sudo lpadmin -p printername ipp://ipaddress-of-printer

or 

 sudo lpadmin -p printername http://ipaddress-of-printer:631
Kurt Pfeifle
  • 86,724
  • 23
  • 248
  • 345