Problems with CUPS

Some of the problems which appear to be CUPS related are actually caused by things like applications producing faulty postscript, here are some hints to keep things going.

Note that MDP and chargeable (AT) print queues go via the IS printing system. You can access their print logs etc via


Login to infcups and run a browser there - connect to http://localhost:631/ (you may need to kill off existing browser windows first) Open a window on infcups and become root.

If a printer has jobs queued but says something like, 'Waiting for job to complete' or 'Printer busy - retrying in X seconds' and nothing is moving. Make sure that the web interface doesn't show 2 jobs for the same printer listed as 'processing'. On infcups do 'ps -fe' and grep for the printer's DNS name (note name e.g. philadelphia not alias if513m1). There should only be one ipp process per printer. You can usually kill off any obviously day or more old processes.

Check the number of the job that's stuck at the head of the queue and do lp -i jobNumber -H hold

this should stop the job at the top of the queue and let the second and subsequent jobs go.

If you have two ipp's processing you may need to hold everything, until you get down to just one ipp. You can then resume the jobs (as above replacing hold with resume ) If you leave it until last you can sometimes even resume the original stuck job, and it'll work. Alternatively just lprm it.

On Canon MFDs you may need to power-cycle the machine if it's chewing bad postscript. It's web interface may show - deleting/canceling. Trying to soft power-cycle just leaves the same hanging state.

-- GordonReid - 30 Jun 2009

Latest problems with LPRng ( this is now mostly obsolete )

This page is intended to be a place where we can make notes about, and hopefully finally arrive at a solution for, the printer problems currently being experienced within Informatics. There seems to be 2 separate problems

  1. print queues get jammed, lpq includes an error message about looping printcaps. This seems to happen after the /etc/printcap file has been recreated.

  1. print queues get jammed, lpq does not report an error but an examination of for a stuck queue shows that jobs are being sent to localhost rather than the printer itself (Actual error messages coming as soon as it happens again).

Error 1. cropped up on powell this morning 5/4/07. An examination of /etc/printcap showed no changes from the printcap used by a working print server. Running top showed that roughly 50% of the cpu was being used up on io wait. Stopping slapd resolved this but when slapd was restarted, the io wait load returned and the printing issue was not fixed. Restarting LPRng also cleared the load and did resolve the printing issue.

-- CraigStrachan - 05 Apr 2007

Edit | Attach | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 14 Jun 2017 - 14:09:17 - NeilBrown
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies