DirtyCleanInterval should be 0 by default

Bug #1830022 reported by Dariusz Gadomski on 2019-05-22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Till Kamppeter

Bug Description

Please consider changing DirtyCleanInterval value to 0 as default.

Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash.

After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost.

Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads.

Test scenario:
1. sudo apt install printer-driver-cups-pdf
2. while [ 1 ]; do lp -d PDF somepdf.pdf; done;
3. # on other terminal
   kill -9 $(pidof cupsd)
4. Note last job number and wait for cupsd to be restarted by systemd.
5. Once accepting jobs is resumend the job counter is rewound.

Expected behavior:
Accepted jobs are queued for processing.

Actual behavior:
Some accepted jobs are lost.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cups (Ubuntu Bionic):
status: New → Confirmed
Changed in cups (Ubuntu Cosmic):
status: New → Confirmed
Changed in cups (Ubuntu Disco):
status: New → Confirmed
Changed in cups (Ubuntu Xenial):
status: New → Confirmed
Changed in cups (Ubuntu):
status: New → Confirmed
no longer affects: cups (Ubuntu Xenial)
no longer affects: cups (Ubuntu Bionic)
no longer affects: cups (Ubuntu Cosmic)
no longer affects: cups (Ubuntu Disco)
tags: added: rls-nn-incoming
tags: removed: rls-nn-incoming
Dariusz Gadomski (dgadomski) wrote :
tags: added: rls-ee-incoming
Changed in cups (Ubuntu):
assignee: nobody → Till Kamppeter (till-kamppeter)
Sebastien Bacher (seb128) wrote :

The problem there doesn't seem common enough to justify being rls tracked, would still be nice to be fixed and it looks like it's being worked without need of special handling, tagging rls-ee-notfixing

Changed in cups (Ubuntu):
importance: Undecided → Low
tags: added: rls-ee-notfixing
removed: rls-ee-incoming
tags: added: sts
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers