MaxJobTime does not match documentation for a value of 0

[nahall]

According to the documentation:

MaxJobTime seconds
Specifies the maximum time a job may take to print before it is canceled. Set to "0" to disable cancellation of "stuck" jobs. The default is "10800" (3 hours).

But setting "MaxJobTime 0" as the document suggests, instead of disabling the cancellation of stuck jobs, causes jobs to be canceled as "stuck" basically immediately. In my testing, perhaps half of the jobs made it through and were printed and half were canceled immediately by CUPS before they could be printed.

Relevant log line:

I [13/Nov/2018:21:41:11 -0600] [Job 2513920] Canceling stuck job after 0 seconds.

[michaelrsweet]

Investigating...

[lathiat]

Analysis from an Ubuntu user who kindly looked into the issue:

I enabled "debug2" log level and tested again. I found the following entries in the log:

d [20/Nov/2018:08:22:25 +0100] cupsdCheckJobs: 1 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1542698545
d [20/Nov/2018:08:22:25 +0100] cupsdCheckJobs: Job 75 - dest="hvitcpdf", printer=(nil), state=3, cancel_time=0, hold_until=1542698845, kill_time=0, pending_cost=0, pending_timeout=0
[...]
d [20/Nov/2018:08:22:35 +0100] cupsdCheckJobs: 1 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1542698555
d [20/Nov/2018:08:22:35 +0100] cupsdCheckJobs: Job 75 - dest="hvitcpdf", printer=0x55faadd92e00, state=5, cancel_time=1542698545, hold_until=1542698845, kill_time=0, pending_cost=0, pending_timeout=0

In the first run of cupsdCheckJobs, the cancel_time of the job is zero, which means to wait indefinitely as expected. In the second run, the cancel_time has been updated to the time of the creation of the job which is wrong.

There is now an individual cancellation time for each job, which is initialized to MaxJobTime if it's not explicitely set. See printers.c around line 3450:

if (!cupsGetOption("job-cancel-after", p->num_options, p->options))
ippAddInteger(p->attrs, IPP_TAG_PRINTER, IPP_TAG_INTEGER,
"job-cancel-after-default", MaxJobTime);

So if MaxJobTime is set to 0 - which means never to kill the job - the default for job-cancel-after is set to 0 - which means to kill the job immediately. So I guess there is a missing check for the special value of 0.

We're tracking this in Ubuntu 18.04 at: https://bugs.launchpad.net/cups/+bug/1804576

Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years)

[michaelrsweet]

Probably best to set the job-cancel-after-default value to "no-value" (IPP_TAG_NOVALUE) so that we don't default it...

[michaelrsweet]

[master 8c71435] Fix handling of MaxJobTime 0 (Issue #5438)

[branch-2.2 3e4dd41] Fix handling of MaxJobTime 0 (Issue #5438)