Bug 215059

Summary: Cancelling job doesn't kill backend
Product: [Fedora] Fedora Reporter: Tim Waugh <twaugh>
Component: foomaticAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: stsp
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 3.0.2-58.fc9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-26 07:09:14 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235705    
Attachments:
Description Flags
cups-cancel.patch none

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 1 Tim Waugh 2006-11-10 13:49:44 EST
(This came out of bug #214280.)
Comment 2 Tim Waugh 2006-11-10 13:50:24 EST
Reported upstream.
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.