Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 625955 - Serial back end has inverted SIGTERM block
Serial back end has inverted SIGTERM block
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Tim Waugh
: Patch
Depends On:
Blocks: 668957
  Show dependency treegraph
Reported: 2010-08-20 19:36 EDT by Bryan Mason
Modified: 2012-02-20 22:09 EST (History)
5 users (show)

See Also:
Fixed In Version: cups-1.3.7-28.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-02-20 22:09:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (447 bytes, patch)
2010-08-20 19:50 EDT, Bryan Mason
no flags Details | Diff
Proposed patch with corrected filename (447 bytes, patch)
2010-08-20 20:02 EDT, Bryan Mason
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 3649 None None None Never
Red Hat Product Errata RHSA-2012:0302 normal SHIPPED_LIVE Low: cups security and bug fix update 2012-02-21 02:24:35 EST

  None (edit)
Description Bryan Mason 2010-08-20 19:36:21 EDT
Description of problem:

    According to the comments in serial.c:

      * Now that we are "connected" to the port, ignore SIGTERM so that we
      * can finish out any page data the driver sends (e.g. to eject the
      * current page...  Only ignore SIGTERM if we are printing data from
      * stdin (otherwise you can't cancel raw jobs...)

    However, the code after that comment is:

      if (print_fd != 0)
    #ifdef HAVE_SIGSET /* Use System V signals over POSIX to avoid bugs */
        sigset(SIGTERM, SIG_IGN);
    #elif defined(HAVE_SIGACTION)
        memset(&action, 0, sizeof(action));

        action.sa_handler = SIG_IGN;
        sigaction(SIGTERM, &action, NULL);
        signal(SIGTERM, SIG_IGN);
    #endif /* HAVE_SIGSET */

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

    1. Define a raw print queue with a serial back end.
    2. Submit a print job (lp -d <printer> <file>).
    3. Cancel the print job (cacel <job-id>).
Actual results:

    Print job does not cancel

Expected results:

    Print job should cancel.

Additional info:

    See upstream STR #3469.

    Patch is on it's way...
Comment 1 Bryan Mason 2010-08-20 19:50:28 EDT
Created attachment 440069 [details]
Proposed patch
Comment 2 Bryan Mason 2010-08-20 19:58:29 EDT
Oops.  Messed up the STR#.  Sorry.
Comment 3 Bryan Mason 2010-08-20 20:02:00 EDT
Created attachment 440070 [details]
Proposed patch with corrected filename
Comment 6 RHEL Product and Program Management 2011-05-31 10:40:37 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 8 Jiri Popelka 2011-09-14 12:29:53 EDT
I wasn't able to reproduce the problem with cups-1.3.7-26.el5_6.1.
My steps:
# lpadmin -p serialraw -v serial:/dev/ttyS0?baud=115200
# accept serialraw
# lp -d -oraw serialraw cupsd.conf
request id is serialraw-10 (1 file(s))
# lpstat -W not-completed
serialraw-10            root              3072   Wed 14 Sep 2011 06:11:08 PM CEST
# cancel 10
# lpstat -W not-completed
<no job>

Any ideas what have I wrong? This is a virtual machine.
Comment 9 Tim Waugh 2011-09-15 11:08:52 EDT
Do virtual machines have serial ports that always accept data or something like that?
Comment 14 errata-xmlrpc 2012-02-20 22:09:42 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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