On Thu, 22 Aug 2019 11:48:37 -0500 (CDT) Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote:> On Tue, 20 Aug 2019, hw wrote: > > > 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? > > 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.
On Sun, 1 Sep 2019 14:19:58 +0200 hw wrote:> 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. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
On Sun, Sep 01, 2019 at 02:19:58PM +0200, hw wrote:> On Thu, 22 Aug 2019 11:48:37 -0500 (CDT) > Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote: > > > On Tue, 20 Aug 2019, hw wrote: > > > > > 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? > > > > 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. >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 -- Jon H. LaBadie jon at jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
On 01/09/2019 13:19, hw wrote:> On Thu, 22 Aug 2019 11:48:37 -0500 (CDT) > Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote: > >> On Tue, 20 Aug 2019, hw wrote: >> >>> 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? >> >> 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. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >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). -- J Martin Rushton MBCS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20190901/97e0fd40/attachment.sig>
On Sun, 1 Sep 2019 11:04:02 -0600 Frank Cox <theatre at sasktel.net> wrote:> On Sun, 1 Sep 2019 14:19:58 +0200 > hw wrote: > > > 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.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.