Bug 215059 - Cancelling job doesn't kill backend
Cancelling job doesn't kill backend
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: foomatic (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks: F9Target
  Show dependency treegraph
 
Reported: 2006-11-10 13:47 EST by Tim Waugh
Modified: 2008-03-26 07:09 EDT (History)
1 user (show)

See Also:
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:


Attachments (Terms of Use)
cups-cancel.patch (1.23 KB, patch)
2006-11-13 11:51 EST, Tim Waugh
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 2092 None None None Never

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.