This is a rather obscure problem, but in case anyone else runs into it, too, here was the fix that worked for us.
We use Printopia Pro to manage our iPad printing, authenticated against Active Directory.
Ordinarily, when students print, we would see the jobs come in as processing and then complete (or processing and then held if the authentication fails).
At a certain point, all the jobs just kept coming as a processing and then just staying that way. None of them ever finished processing.
When I looked into the /var/log/cups/error_log file, I saw this error repeated:
hello – printing was working fine for months for our thin clients – now they are not able to print – i checked the CUPS error log and it seems to show ‘Returning IPP client-error-not-possible for Print-Job’ whenever a client tries to print. Any ideas?
not sure how I fixed it exactly – tried restarting cups, didn’t work – tried canceling all jobs – didn’t work, tried printing a test page and it said there were too many jobs…so i added MaxJobs 0 to the .conf file, restarted cups and now everything seems to print again.That’s what ended up working. Be sure to stop the CUPS service before editing the config file:
According to the CUPS documentation…
The MaxJobs directive controls the maximum number of jobs that are kept in memory. Once the number of jobs reaches the limit, the oldest completed job is automatically purged from the system to make room for the new one. If all of the known jobs are still pending or active then the new job will be rejected. Setting the maximum size to 0 disables this functionality. The default setting is 500.…so I’m not sure I get why this fixes things. In theory, with the default setting of 500, once new jobs came in, the older jobs would be purged automatically. In any case, that’s the setting that worked to fix the problem. If you get that obscure CUPS error, it may fix yours, too.