Comment 1 for bug 1804576

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.