Bug 456942 - libprintbackend-lpr.so does not print until application exits
libprintbackend-lpr.so does not print until application exits
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution28-gtk2 (Show other bugs)
4.7
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Matthew Barnes
Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-28 15:28 EDT by Dan Astoorian
Modified: 2010-10-22 23:13 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
* the I/O channel for GTK's Line Printer Remote (LPR) backend remained open even after data transfer was complete. Printing will not start until this channel is closed, so pages from Firefox 3 would not begin to print until the browser closed (since this would also close the channel). GTK's LPR backend now closes the I/O channel when data transfer is complete, and printing commences immediately.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 16:34:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 390159 None None None Never

  None (edit)
Description Dan Astoorian 2008-07-28 15:28:35 EDT
Description of problem:
The lpr print backend library does not close the file descriptor to the lpr
command promptly.  (cf. GTK+ bug ID #390159,
"(gtk_print_backend_lpr_print_stream): Close the io channel on unref."); see
http://bugzilla.gnome.org/show_bug.cgi?id=390159 for further details.

Version-Release number of selected component (if applicable):
evolution28-gtk2-2.10.4-22.el4
(reproduced using firefox-3.0.1-3.el4)

How reproducible:
Always

Steps to Reproduce:
1. Configure gtk+ to use the lpr backend (e.g., by putting the line
  gtk-print-backends = "file,lpr"
into the user's ~/.gtkrc-2.0 file or one of the system gtkrc files
2. Launch Firefox 3.0.1 ("/usr/bin/firefox")
3. Print a page using the "Print to LPR" option in the print dialog.

  
Actual results:
The page does not print until the browser has been closed; running "ps" displays
that an lpr child process of firefox 3 is still running.

Expected results:
The page should print immediately and the lpr process should not remain.

Additional info:
Replacing the libprintbackend-lpr.so library with a more recent version
eliminates the symptom, so the bug is definitely in this library and the fix
appears to have been added at or around release 2.11.0.

We are not able to work around this by using the default CUPS backend, as our
accounting procedures require print authentication (and password prompting is
not implemented in this GTK+ package either).
Comment 1 Matthew Barnes 2008-07-28 15:43:16 EDT
Reassigning this to Matthias.  (you're welcome :)
Comment 2 wdc 2009-01-15 12:03:57 EST
So the fix is known; The only work-around is to take an upstream update to the lpr back end, and yet this has sat for five months with no visible forward progress?

There are 1000 RHEL 4.7 users at MIT who are going to start calling the help desk wondering why they can't print from Firefox any more.  This is a serious regression and deserves high priority remedy, I think.
Comment 12 Ruediger Landmann 2009-02-05 20:27:05 EST
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
* the I/O channel for GTK's Line Printer Remote (LPR) backend remained open even after data transfer was complete. Printing will not start until this channel is closed, so pages from Firefox 3 would not begin to print until the browser closed (since this would also close the channel). GTK's LPR backend now closes the I/O channel when data transfer is complete, and printing commences immediately.
Comment 13 wdc 2009-02-06 00:25:19 EST
That release note looks 100% accurate to me.
Comment 16 Richard Cunningham 2009-03-02 07:18:18 EST
Is there a updated (beta or released) RPM for this?

Also this exists in RHEL5 too, does that need a separate bug report?
Comment 19 Robin R. Price II 2009-03-02 16:34:25 EST
Richard,

Thanks to Tim Waugh,  I rolled an rpm from a patch he created for this issue
and the results have been positive. RHEL4.8 should have the fix for this and
will be going into beta for testing very shortly.  Also, there is a hotfix
being processed for this issue with RHEL4.8.  I would open a support ticket
regarding the issue to get the supported bits.  I would also advise you to open
up a new bugzilla regarding this for RHEL5 but mention this bugzilla in the
description.  If you have a support contract, I would like to urge you to open
a support ticket with RHEL5 and we can try to get a hotfix processed for you
and others running into the problem.

-- Robin
Comment 21 errata-xmlrpc 2009-05-18 16:34:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1021.html

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