Bug 24512 - rpm does not close pipes correctly
rpm does not close pipes correctly
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: gpm (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
David Lawrence
:
: 36400 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-21 13:50 EST by Gerald Teschl
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-09 10:59:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gerald Teschl 2001-01-21 13:50:00 EST
If I pipe the rpm output to another command, it sometimes happens that rpm
does not close the pipe correctly. The other command will wait forever
while rpm already terminated.

For example. Suppose you have

gpm-1.19.3-6.i386.rpm        gpm-devel-1.19.3-6.i386.rpm

installed and you say

rpm -vF gpm-1.19.3-7.i386.rpm gpm-devel-1.19.3-7.i386.rpm | grep gpm

then rpm will finish but grep waits forever.
Comment 1 Glen Foster 2001-01-22 12:41:04 EST
This defect is considered MUST-FIX for Florence Gold release
Comment 2 Jeff Johnson 2001-01-22 13:10:56 EST
This is a gpm packaging problem, verifed by doing
	rpm -Fv --noscripts gpm* | grep gpm
Comment 3 Gerald Teschl 2001-01-23 11:48:16 EST
It happens with other packages as well.
Comment 4 Gerald Teschl 2001-01-23 13:08:59 EST
For example with:

autofs-3.1.7-5
openssh-2.3.0p1
vixie-cron-3.0.1-57

Could it be that this is related to #18988 ?

I still think this is an rpm and not a gpm/openssh/packaging problem.
Comment 5 Gerald Teschl 2001-01-24 07:01:44 EST
I just had another look at the problem. The gpm daemon still has the pipe open
for writing
after rpm has quit. However, since gmp is restarted as

service gpm stop >/dev/null 2>&

in the post script, it doesn't have the pipe as STDOUT/ERR but /dev/null. So
where did it get it
from?
Comment 6 Preston Brown 2001-01-31 17:33:49 EST
still an RPM issue.
Comment 7 Jeff Johnson 2001-02-01 09:17:30 EST
Again, I repeat:

If you install gpm with --noscripts, the install does not "hang". That means
that the
problem is in packaging,  and the fix is in packaging, and the bug report needs
to
be against the package(s), not rpm, as there's no way that I can "fix" (i.e. by
changing the
execution environment of rpm scriptlets) without introducing legacy
incompatibilities (i.e. by
changing the execution environment of rpm scriptlets) at this point in a release
cycle.

So, back to gpm, which needs to close open file descriptors when starting as
daemon.

Please open separate bugs for the "me too" packages, as this bug is about gpm,
and it's
unclear whether the other packages have this or another problem.
Comment 8 Glen Foster 2001-02-01 10:43:49 EST
This defect has been removed from the Florence Gold MUST-FIX list
Comment 9 Gerald Teschl 2001-02-09 10:59:27 EST
My guess is the following: Rpm redirects stdout/err but keeps a copy of the
original stdout/err so it can be restored later. Then it does a fork and the
child execs the script. However, the
child does forget to close the copy of the filehandle and so all subsequent
processes inherit it.
Comment 10 Preston Brown 2001-06-25 13:14:57 EDT
looking through the code, it looks like there are several reasons that stderr isn't 
closed during startup of gpm.  Here's a comment:

  /* FIXME: stderr must be closed at this point, as protocol init needs it */ 

As this bug isn't critical, and it seems we might introduce more problems than we 
solve by messing with the code, I'm closing this WONTFIX.
Comment 11 Preston Brown 2001-06-25 13:17:06 EDT
*** Bug 36400 has been marked as a duplicate of this bug. ***
Comment 12 Preston Brown 2001-07-19 12:00:58 EDT
*** Bug 36400 has been marked as a duplicate of this bug. ***

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