Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Cancelling job doesn't kill backend|
|Product:||[Fedora] Fedora||Reporter:||Tim Waugh <twaugh>|
|Component:||foomatic||Assignee:||Tim Waugh <twaugh>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||3.0.2-58.fc9||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-03-26 07:09:14 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Tim Waugh 2006-11-10 13:47:46 EST
Description of problem: When cancelling a job, the backend ignores SIGTERM and continues printing. I understand this is due to the desire to allow the filter to make the printer eject the page or otherwise finish the job off cleanly, but it means that (a) the printer buffer and (b) the pipe buffer between the filter and the backend get to spool onto the printer even after the job is cancelled. There must be a better way! For example, the parallel backend ought to be given the opportunity to reset the device. Version-Release number of selected component (if applicable): cups-1.2.5-2.fc6.8
Comment 2 Tim Waugh 2006-11-10 13:50:24 EST
Comment 3 Tim Waugh 2006-11-13 11:51:03 EST
Created attachment 141071 [details] cups-cancel.patch Saving this proposed patch here in case it gets lost. This just cancels jobs that have not yet started printing. The full fix will be upstream in 1.3.x.
Comment 4 Stas Sergeev 2007-07-20 15:34:43 EDT
> When cancelling a job, the backend ignores SIGTERM and continues printing. I > understand this is due to the desire to allow the filter to make the printer > eject the page or otherwise finish the job off cleanly IMHO, this is wrong. SIGTERM is a SIGTERM. It can ignore SIGHUP or SIGINT, but SIGTERM should terminate right away, I think. There are many signals, all with the different meaning. I think it is not good to have an apps that you can reliably kill only with SIGKILL. > Saving this proposed patch here in case it gets lost. This just cancels jobs > that have not yet started printing. The full fix will be upstream in 1.3.x. Will the "full fix" do the same (cancel only whatever was not started), or something different? I don't think in my case the printing was not started, so I don't see how that logic can fix my problem.
Comment 5 Tim Waugh 2008-02-26 10:21:27 EST
This is all working in 1.3.6 except for the fact that foomatic-rip doesn't clean up its forked processes. Changing component to foomatic.
Comment 6 Stas Sergeev 2008-02-26 13:40:51 EST
If possible, could you please give me the link to the appropriate changelog entries or commits, so that I can figure out what was done and what can be tested? Eg, should I now send a SIGTERM to "parallel" and see if it stops the job, or something else.
Comment 7 Tim Waugh 2008-02-26 13:47:52 EST
SIGTERM gets sent to the backend and to all filters. The CUPS backends ignore SIGTERM in order that the filters can perform any cleanup necessary (such as ejecting the page or resetting the printer). Any remaining problems are with the individual filters. The commonly used foomatic-rip filter is known not to clean up correctly when sent SIGTERM, and instead just keeps sending out job data.
Comment 8 Stas Sergeev 2008-02-26 14:03:52 EST
Btw, in my case, if you remember, the parport driver in kernel is faulty. I don't think ejecting the page or resetting the printer will really work in that case (will probably jam just a few more pages instead). Is there only a SIGKILL to bypass also that? So I still think the SIGTERM should just terminate instead, but of course everything is far better than to keep sending the data out.
Comment 9 Tim Waugh 2008-03-26 07:09:14 EDT
The foomatic-rip in rawhide (foomatic-3.0.2-58.fc9) is now fixed for this issue.