For over a year now, we've not been able to find the resolution to an on-going CUPS configuration issue. Everyone on the Linux/CUPS forums have said as long as the cups default is set to "retry print" when there is a printer issue, we've never gotten that to work. Recently one of our printers broke totally, we "re-directed" the bulk of the print jobs by changing user default printers in our applications, however, the print jobs that were on the queue prior to that, got stuck. Our SA noticed today that although the CUPS config file on our Linux system is set to "retry", when he logs into the GUI for CUPS - it is set as "STOP PRINTER". So, my question is this, if the GUI is seeing "STOP PRINTER" but the CUPS config on the system is set correctly, what other file(s) might need to be changed? Does anyone on here have knowlege of CUPS/Linux (SuSe)? Our SA can "resend" each print job manually using the GUI, but that is time consuming, so we're trying to find the proper resolution so that when a printer is "fixed" that the print jobs in the queue will auto-restart.
you should set this up so your apps and users send print jobs to a queue and not to specific printers. then the printer(s) draw jobs from their queues and print them. then if you have to assign a different printer nobody has to change where they send the jobs. also, you can also have several printers draw from one queue if you want or need to.
is that how you are doing it?
Gus, not sure if I follow.
Our environment is as follows:
1. Each printer is defined a printer queue on each Linux system where users might print to that printer.
2. Each linux system has their own print server (we don't have just one print server but many).
3. Our Progress APPS have printers defined (which use the defined printer queues)
4. Each user has a defined default printer - and then can select another printer if they need to print elsewhere in the company. Typically, they only print to a printer in their general work area.
5. we use the lp command from w/in 4GL code to send print jobs to specific printer queues.
The problem we are seeing with CUPS and using the command cupsenable, after a printer has been down/broken. This that command doesn't appear to "resend" all jobs still in that printer queue to the printer. We noticed that on a different linux system (running a different os version/level) still has the old "enable" command and that does resend the print jobs hung on a queue to the now fixed printer.
What we've been trying to figure out is what is the cause of the difference between "cupsenable" vs "enable" commands (as they are supposed to be essentially the same...and what other config files we might need to check on the one host that doesn't seem to work properly...as our SA has not yet found the cause.
We've googled & searched many CUPS/Linux forums and the answers there have said to just re-enable the print queue and the print jobs should print...but they don't for one of our Linux systems. We have to go into the GUI software for CUPS and resend each print job still hung on the print queue. This is obviously not desired - as it's extremely time consuming when we have several days of hung jobs.
Another point, is that sometimes printers break and we're not notified right away, and there are automated print jobs that print - so they get hung as they can't print. There are times we can resolve this by changing the user's ID to a different printer/queue defined for that system...but sometimes we can't as some are not based on user id but are "hard coded"...and yes, I know, hard-coding might not be good or best practice...but that's what has been done and we have to live with this limitation for now...until I can convince powers to be to enhance the script/processes so that we woudn't need to change a program to change the printer for the report(s).
I've posted on several Linux & CUPS forums...to no avail...was hoping that maybe someone on the PEG or Progress community might've run across this issue before.