After getting advice at http://www.linuxquestions.org/questi...d.php?t=534221 a few months ago, I set up a print server using CUPS, and it has worked great. About once a month, though, the print queue gets "stuck" and I've cured this by deleting the printer on the server, then reinstalling the identical printer with the same name and everything. I don't want to change the printer's name lest the users get confused. All the old print jobs then become visible again via the printer's web server, but the pending jobs in the stuck queue are gone and the queue then works fine again. I would have thought deleting the printer would wipe ALL previous information and start from a clean slate, but I didn't worry about it because this has always fixed the problem, until now.

I just did this uninstall/reinstall operation, but this time the queue remained stuck, and the list of pending jobs in the stuck queue never cleared. I tried uninstalling-rebooting-reinstalling, but that didn't help, so I simply uninstalled the printer and set up a different node as the print server, and that solved the problem.

But how do you clear the print server entirely and correctly? That seems like the best bet to solve the problem, which apparently is eventually going to arise on whichever client I set up as a print server.

You can use http://localhost:631 then delete by clicking a few times. If it's many jobs then you can use a script with a for loop that calls the '/usr/bin/clear' command; you can then create a cron job that runs this script every half hour or so - I did that once and it worked very well.

Using the web interface to remove jobs has never worked. I always get the error "Forbidden. You don't have permission to access the resource on this server." I get that error whether I'm working directly on the print server or another client. We've never had a need to use the web interface this way, so I've never worried about it.

As far as I know, /usr/bin/clear clears the terminal screen, so I can't tell exactly what you're suggesting.

My aim here is to be able to remove the printer ENTIRELY from the operating system, not just queued jobs, and install it clean. Isn't there some set of directories and files somewhere that can be emptied to clear the print server manually? Presently, when I remove and reinstall, the system knows to associate the new printer with the old queue, I assume based on my using the same printer name. I presume the system must maintain a database somewhere of the printers it's serving. How can I clear that database?

CUPS gets the printers list from printers.conf ( in my case in /etc/cups ). Delete the printer from the file and restart CUPS and the printer will be gone.
Check your cupsd.conf for the directory where the spool files are being kept ( probably /var/spool/cups ). When you are reinstalling your printer with the same name, CUPS is probably detecting the presence of the old spool files.
While looking at cupsd.conf and the spool directory, check for permission problems that are causing the error message when you try to delete jobs using the web interface.

Thanks, Allend. I see the completed print jobs in /var/spool/cups and I presume the /var/spool/cups/tmp directory holds the active jobs. Next time I get the "stuck" printer queue, I'll make sure these directories' contents are deleted before I reinstall the printer. My procedure has been to uninstall/reinstall with no delay, but I'm now thinking that when you uninstall the printer via the desktop gui, the system (cupsd?) takes a while to come along and clear the queue and perhaps do other maintenance. So by reinstalling the same printer with no delay, the queued jobs never get cleared.

Interestingly, I tried deleting a completed job manually, but then I saw that same job still appeared via the web interface on port 631. Also, in once case I uinstalled/reinstalled and the queue was cleared, but the new jobs were numbered starting from where the old queue left off. So clearly the system's management of the queue is a little more complicated, or relies on information stored somewhere else.

I checked the permissions as you suggested, but it's not obvious to me what they should be. /var/spool is 755, and I tried setting /var/spool/cups/* to 777, but I still can't control jobs from the web interface. By the way, even though the web interface shows the queues properly, its icons never load, except when I'm on the client running the print server and I browse to localhost:631. That appears to be some sort of permissions issue too. And when I try to remove a job while browsing on the server to localhost:631, I don't get the generic "Forbidden" page I described above, but I get an error page from the CUPS web interface that says the error was "client-error-not-possible." The different appearances of the "forbidden" type error also indicates permission issues, but I just don't see where to look. Maybe if I knew where the web interface keeps its icons, that might provide a clue.

Sorry. The command that I meant was /usr/bin/cancel. This command allows you to delete print jobs. I had the same problem in the past and I created a looping script that allows me to detect hung jobs every 5 minutes and delete them if necessary.

Deleting and reinstalling the printer does not sound like a solution.

I had a similar problem where my printer would show up as unavailable and no jobs could be sent to it, although the /var/log/samba/ logs showed a job being sent, the cups logs did no show a job with the same timestamp. I managed to solve the problem and get the printer working again by deleting (actually I moved them first!) the /var/cache/samba/printing/printers.tdb and <printer_model_here>.tdb files. Seems there was corrupting in these tdb files.

I'm now trying to find out how to prevent this from happening again.

Any ideas?

I have had the same problem several times and removed-reinstalled the printer in cups every time also. Today it happened again and I think I found the solution.
lpstat -t will give you the status of (all) your printer(s).
The problem-printer will probably be disabled.
Then lpadmin -p <printername> -E will reenable it.

Question remains: what is causing this nuisance?
My printer is a usb printer connected to the file server running cups. The problem occurs mostly on my laptop which connects wirelessly to the file server.
Where/when does it occur with other people?

Regards,

Bert

This is a pretty basic service for which I was able to find surprisingly little help. I talked to other system administrators who said they basically had to constantly babysit the print queue. That's what I had to do, but since this lab can't hire a full-time babysitter, sadly, there were enough screaming complaints from a few computer illiterate users to the computer illiterate management who simply decided to replace everything with Windows. They spent a lot of money buying new computers they didn't need, even for Windows, but their now all-Windows clients with a printer on a static ip with no print queue management of any kind works just fine. I can't say I blame them for taking this route, and what they have does work, even though in their panic and distrust of my recommendations they wasted a lot of money and the printer sits there unsecure on the network, without a password, without access logging, for anyone in the world to mess with. I think it's a bad sign for Linux that such an absolute must-have for users (printing) makes for such a dealbreaker and sends people running hysterically for Windows. This office was particularly bad because the boss I'd worked with for years moved on, and despite his recommending me to the new boss, her first impression of me was a million people complaining about the substandard printing situation. So I'm fired from a part-time job (with way too few hours to give them the support Linux printing apparently requires), and they retained a very expensive support staff who's available 24/7 and who aren't any better than me, but aren't tainted by their recommendation of Linux.

So in your basic word processing/printing/internet surfing office, I don't think Linux competes for the user experience as well as Windows or Mac, due to this print queue deficiency and Open Office's inability to trustworthily duplicate enough of Microsoft Word.

To be able to manage the cups printing jobs through web, you need to login first. Click on the "Administration" icon at the top of page http://localhost:631, it will prompt for user name and password.

sudo rm -r /var/spool/cups/

will do the trick

Brilliant! Thanks so much. This is the exact same solution Allend offered above on 6-27-07. Thanks for reading the thread so closely and repeating the same information because I didn't have much incentive to read what people said the first time.

I was fired from this job more than two years ago because of the stuck printing queue problem, and they bought a bunch of very expensive Macintoshes, a more expensive service contract, and they're using the same networked printer. I will miss all the free assistance I used to get with complicated Linux problems like using a network printer, which Windows and Mac OS have somehow turned into no-brainers.

I doubt that this why you were fired when you make comments like:

Good analytical work there based on your broader store of information and your eyewitness account. You've convinced me that people's accumulated reports of printer failure had nothing to do with it. My boss must have lied to me and the working Macintoshes must have been a false report. You told me so real good.

Despite the attitude of JimmyTheSaint, he's got a point. This is a continuing issue for me when testing Linux printing too.