Bug 364321 - misused pipe breaks update of selinux-policy-targeted
misused pipe breaks update of selinux-policy-targeted
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
: 365011 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-11-02 13:28 EDT by Alexandre Oliva
Modified: 2014-01-21 17:59 EST (History)
5 users (show)

See Also:
Fixed In Version: 3.2.8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-06 22:54:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2007-11-02 13:28:21 EDT
Description of problem:
yum starts rpm scripts with their outputs set to a pipe that only the yum
process itself can read from, and waits for them to complete before it will
attempt to read from the pipe.

If the scriptlet generates more output than the pipe buffer, (e.g., fixfiles run
by the selinux-policy-targeted update), the update will hang forever

Version-Release number of selected component (if applicable):
yum-3.2.7-1.fc7 updating to selinux-policy-targeted-2.6.4-49.fc7

How reproducible:
Every time

Steps to Reproduce:
1.ssh hostname -l root yum -y update selinux-policy-target
Actual results:
Prints "Updating selinux-policy-targeted" progress bar then deadlocks wait()ing
for the rpm %post script to complete, while restorecon and fixfiles write to the
pipe whose buffer is full and nobody is reading from.

Expected results:
No such deadlock, output buffered in separate thread or process or sent straight
to the update initiator.

Additional info:
cat /proc/<yumpid>/fd/32 (that was the read end of the pipe) enabled the update
to complete on my end.  The file descriptor was the same on two different
machines, but then, the same updates were running on them, so I can't tell
whether it was just a coincidence or something that can be relied upon.
Comment 1 Jeremy Katz 2007-11-05 10:42:16 EST
*** Bug 365011 has been marked as a duplicate of this bug. ***
Comment 2 Seth Vidal 2007-12-06 22:54:56 EST
This is closed in 3.2.8 in updates released!

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