Bug 1301908 - rpm update hangs when ldconfig is executed in post section [NEEDINFO]
rpm update hangs when ldconfig is executed in post section
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm (Show other bugs)
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Florian Festi
BaseOS QE Security Team
Depends On:
Blocks: 1465896
  Show dependency treegraph
Reported: 2016-01-26 05:53 EST by Oliver Haessler
Modified: 2018-01-01 20:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ffesti: needinfo? (oliver)

Attachments (Terms of Use)

  None (edit)
Description Oliver Haessler 2016-01-26 05:53:34 EST
Description of problem:
When updating from RHEL 7.1 to 7.2 several RPMs need a long time to update (it looks like the update hangs when done via yum)

Version-Release number of selected component (if applicable):

How reproducible:
Everytime you update a RHEL 7.1 workstation to RHEL 7.2 via yum update

Steps to Reproduce:
1. Update a RHEL 7.1 workstation to RHEL 7.2 via yum update

Actual results:
Wait time below are taken from yum.log during yum update. While it waits for waitpid, the actual PID it is waiting for (like 2187) is not showing in "ps" any loner, neither is a ldconfig process showing. It looks like e.g. ldconfig is finishing too fast and it runs into a timeout during update.

wait time for kmod-20-5.el7.x86_64:
Jan 26 11:13:05 Updated: kmod-20-5.el7.x86_64
Jan 26 11:23:25 Updated: systemd-219-19.el7.x86_64

wait time for libgovirt-0.3.3-1.el7.x86_64:
Jan 26 11:23:56 Updated: libgovirt-0.3.3-1.el7.x86_64
Jan 26 11:28:07 Installed: geoclue2-2.1.10-2.el7.x86_64
D: %post(libgovirt-0.3.3-1.el7.x86_64): scriptlet start
D: %post(libgovirt-0.3.3-1.el7.x86_64): execv(/sbin/ldconfig) pid 2187
D: %post(libgovirt-0.3.3-1.el7.x86_64): waitpid(2187) rc 2187 status 0

wait time for libGLEW-1.10.0-5.el7.x86_64
Jan 26 11:33:24 Updated: libGLEW-1.10.0-5.el7.x86_64
Jan 26 11:35:24 Updated: pulseaudio-6.0-7.el7.x86_64
D: %post(libGLEW-1.10.0-5.el7.x86_64): scriptlet start
D: %post(libGLEW-1.10.0-5.el7.x86_64): execv(/sbin/ldconfig) pid 3611
D: %post(libGLEW-1.10.0-5.el7.x86_64): waitpid(3611) rc 3611 status 0

wait time for ekiga-4.0.1-5.el7.x86_64
Jan 26 11:36:32 Updated: ekiga-4.0.1-5.el7.x86_64
Jan 26 11:40:33 Updated: 1:NetworkManager-openvpn-1.0.8-1.el7.x86_64
+ /usr/bin/gtk-update-icon-cache --quiet /usr/share/icons/hicolor
D: %post(ekiga-4.0.1-5.el7.x86_64): waitpid(4479) rc 4479 status 0
Comment 2 Oliver Haessler 2016-02-19 08:45:08 EST
do we have any update on this? Every RHEL 7.x to 7.2 update I am running takes at least 3 times longer than it should need.
Comment 5 Florian Festi 2017-10-13 05:27:39 EDT
Looking into this it is highly unlikely that the issue is caused the way it is proposed here. According to the waitpid documentation this is just not possible. 

Is the rpm process actually hung in waitpid when looked at with strace? The output of the yum log file can be deceiving as some lines might be printed delayed.

My suspicion is that the hang up are actually when updating the rpmdb which is what appends right after running the %post scriptlets. There are know issues that can result in the performance of the rpmdb degrading. Especially many updates to the rpmdb can degrade the internal structures of the bdb. They can be magnified by other circumstances like huge installations and/or many files with the same basename.

If this is the case the performance should improve after rpmdb --rebuild.

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