mitprint local pharos queue occasionally gets stuck

[achernya]

The mitprint local pharos queue currently has a policy of stopping the printer when an error occurs. While this makes sense for a real printer, for the forwarding queue, this means that all subsequent jobs get stuck. Linerva recently noticed that there were over 80 stuck jobs, and repeated "cupsenable mitprint" followed by removing the jobs causing an error, were the only way to fix this.

This has consequences for cluster machines, as well as the dialups, where a user can cause a denial-of-service by sending bad jobs.

Arguably, the on-error policy should be to drop the job, not stop the "printer" (forwarding queue).

[jdreed]

So, as of Precise, the default ErrorPolicy? is retry-job, which means retry after 30 seconds. On Linerva it's stop-printer, which is clearly wrong, and I'm waiting to find out what it is on the dialups. Arguably, cups-config should force it to be retry-job. OTOH, perhaps abort-job is the right answer? I mean, most jobs that fail are bad PDFs, and it's not like the PDF will magically fix itself. We should also consider setting JobRetryLimit? to something less than 5.

[kaduk]

Replying to jdreed:

So, as of Precise, the default ErrorPolicy? is retry-job, which means retry after 30 seconds. On Linerva it's stop-printer, which is clearly wrong, and I'm waiting to find out what it is on the dialups. Arguably, cups-config should force it to be retry-job. OTOH, perhaps abort-job is the right answer? I mean, most jobs that fail are bad PDFs, and it's not like the PDF will magically fix itself. We should also consider setting JobRetryLimit? to something less than 5.

I would be happy to see either abort-job or retry-job with JobRetryLimit? of 2.
I occasionally have jobs where the printer gets sad in the middle of the first copy and a second copy is sent, but I don't remember there ever being a successful third or later try. I do remember successful second tries after a failed first try.

[jdreed]

r25826