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
(This came out of bug #214280.)
Reported upstream.
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.
> 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.
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.
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.
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.
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.
The foomatic-rip in rawhide (foomatic-3.0.2-58.fc9) is now fixed for this issue.