Ticket #1271 (closed defect: fixed)

Opened 8 years ago

Last modified 8 years ago

mitprint local pharos queue occasionally gets stuck

Reported by: achernya Owned by:
Priority: high Milestone: Current Semester
Component: printing Keywords:
Cc: Fixed in version: debathena-cupsys-config 1.17.5
Upstream bug:

Description

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).

Change History

comment:1 follow-up: ↓ 2 Changed 8 years ago by 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.

comment:2 in reply to: ↑ 1 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by jdreed

  • Status changed from new to committed
  • Fixed in version set to debathena-cupsys-config 1.17.5

comment:4 Changed 8 years ago by jdreed

  • Status changed from committed to development

comment:5 Changed 8 years ago by jdreed

  • Status changed from development to proposed

comment:6 Changed 8 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.