Red Hat Bugzilla – Bug 215059
Cancelling job doesn't kill backend
Last modified: 2008-03-26 07:09:14 EDT
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):
(This came out of bug #214280.)
Created attachment 141071 [details]
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.