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 descriptor. 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.