From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
gpm does not close its file descriptors on startup, like a properly
written daemon should. (It does chdir to / and setsid() and background
itself, though.) So it retains a reference to its standard out file
This isn't ordinarily harmful at boot time, but it can be in other
contexts. Particularly, the gpm RPM postuninstall script does an
/etc/init.d/gpm condrestart if $! -ge 1. (I don't know how common that is
for Red Hat RPMs of daemon programs.) The resulting gpm can retain a
reference to the rpm command's standard output; if that output is being
piped through another program, then that program's input won't be closed
and the program won't terminate.
Reproducible: Couldn't Reproduce
Steps to Reproduce:
Theoretically this shouldn't be too hard to reproduce, but I wasn't able
to do it on the system I currently have access to. What you should need
is two relatively recent version of the gpm RPM; install the older one and
then "rpm -U newerone | cat". The command should fail to terminate
because gpm is holding a reference to "cat"'s input.
Hi. My bug report still stands, but some of the details in my description were
wrong. It turns out that the actual symptoms I witnessed were caused by a bug
in RPM (which I've reported, #37695), and that /sbin/initlog normally covers up
for daemons which don't take responsibility for closing file descriptors (by
redirecting fds 0/1/2 prior to Red Hat 7.1, and by also closing other file
descriptors in Red Hat 7.1).
Also, my exact description of what gpm should be doing was imprecise. What I
meant to say is that all properly written daemons should redirect file
descriptors 0/1/2 to /dev/null, and that gpm does not do this.
*** This bug has been marked as a duplicate of 24512 ***
Bug number 24512 is restricted such that I am not allowed to read it.
I am not sure precisely what principles the Red Hat bug tracking service
operates on, but it doesn't seem acceptable under any reasonable
principles to resolve a user's bug report as a duplicate of a confidential
bug. So I'm reopening this bug.