CUPS Job Handling
Hi,
is it somehow possible to make CUPS automatically redirect jobs, and following jobs, away from printers which can not print them to other printers that can print them until the printers that couldn’t print them are again able to print them?
Like I have a bunch of label printers which are all the same, and all of which are prone to run out of labels or out of ribbon every now and then. It can take hours or even days before someone can refill a printer. Hence it would be very useful if CUPS could be told something like “if printer A doesn’t print, move its current job to printer B and divert all new jobs sent to A to printer B instead until A prints again”.
What exactly happens when a printer that is member of a class can not print a job that was sent to the class? Will the unprintable job be automatically moved to another member of the same class, or will it only be aborted and never printed?
With a class of two printers and one of them running out of labels,
/var/log/cups/error_log only holds:
… [Job 174733] Stopping unresponsive job.
What does this mean? Has the job been printed or not? Has it been printed after I refilled the printer?
6 thoughts on - CUPS Job Handling
IIRC CUPS has printer classes or some such thing. A user can send a job to a class and CUPS will direct it within that class as it sees fit. Presumaly if one printer is stil chewing on last week’s job, CUPS will see fit to direct subsequent jobs elsewhere.
Well, yes, and I am not sure (at least not yet) if print jobs for a class are diverted to other members of the class or not. It seems that data kept in the printer buffer and in the print-server the printers are connected to can make it difficult to figure what is actually going on.
A much bigger problem are printers that are not members of classes, though. Such printers are not members of classes because they are at physically different locations, and employees would have to go to from one printer to another to collect the lables.
Yet if a printer doesn’t print anymore, it is desirable to divert jobs to another printer, preferably a designated fallback. It is of no use when the jobs get stuck in the queue until the printer is being maintained which can be days later.
You might want to write a program that will check the printer queues on a regular basis and re-route the job if the printing stops.
lpstat will tell you what’s going on with the printer (check queue, is it online, etc)
I don’t know if there’s an “official” way to recover a print job (you can research this yourself), but they are stored in /var/spool/cups so you could pull them directly from there if needed.
A bit of glue code to link all of that together (check printer status every X minutes, if the next pending job from the last check is still not printing then recover all of the incomplete jobs, cancel the printing on the local printer, re-route the recovered jobs to a different printer) and you’ll be all set.
With the widespread use of deskside printers today, the use-case for printer classes is moot. Back when laser printers were expensive, a department might purchase several of the same printer and put them into a “printer room” along with “cubby holes” for each department member. So you might have printers enumerated hplj-1
to hplj-n and a printer class just hplj. If you printed to hplj, the first unused member of the class got your job. But you could still send to a specific printer by enumerated name.
Another seldom used feature is cover sheets (and end sheets). They separated users jobs so when you picked up your job directly from the printer, you could file other completed jobs in their respective cubbies.
Jon
Jobs sent to a class will be queued on the first printer in that class that is available. For instance if the class “Laser” contains the printers “WiFiPrinter” and “ColourLaser” jobs will be sent to WiFiPrinter. If, however, WiFiPrinter is switched off then after about a minute the job is requeued to ColourLaser.
As regards moving jobs from non-class printer, have a look at lpmove(8).
It would take a lot more than a “bit of glue code” to do it, and it might never work reliably. There’s also probably no way to divert jobs while a printer is disabled before they are being sent. And what about jobs stored in the buffers of printers and print-servers? A job stuck in a buffer and is no longer in the queue may be kinda difficult to divert.
And how I do distinguish between a printer that is set to offline because someone didn’t (intentionally) press the button and a printer which is not online for other reasons?
It’s probably a bad idea unless all relevant information is available. That’s why it needs to be done by CUPS itself — and even CUPS may not have all the information.