** Changed in: cups (Ubuntu Trusty) Status: New => Invalid ** Description changed:
[Impact] - Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. + Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] - 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. - 2. Setup a filter that takes at least several seconds to process. - (please find a sample imagetopdf wrapper introducing 5s delay) - 3. Submit a print job matching the filter, e.g. - lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper + 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. + 2. Setup a filter that takes at least several seconds to process. + (please find a sample imagetopdf wrapper introducing 5s delay) + 3. Submit a print job matching the filter, e.g. + lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] - The scope of the change is limited to fixing the MaxJobTime handling - in scheduler/job.c and scheduler/printers.c. There should be no - difference in behavior except for the special value of MaxJobTime=0. - + The scope of the change is limited to fixing the MaxJobTime handling + in scheduler/job.c and scheduler/printers.c. There should be no + difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) + + Trusty is not affected by this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: New Status in cups package in Ubuntu: In Progress Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: In Progress Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp