On Sun, 1 Sep 2019 11:04:02 -0600 Frank Cox <thea...@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. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
