Bug 1301908

Summary:	rpm update hangs when ldconfig is executed in post section
Product:	Red Hat Enterprise Linux 7	Reporter:	Oliver Ilian <oliver>
Component:	rpm	Assignee:	Florian Festi <ffesti>
Status:	CLOSED EOL	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	oliver, vmukhame
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-08 11:21:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1465896

Description Oliver Ilian 2016-01-26 10:53:34 UTC

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):
rpm-4.11.3-17

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
2.
3.

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 Ilian 2016-02-19 13:45:08 UTC

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 09:27:39 UTC

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.

Comment 9 Oliver Ilian 2018-10-08 11:21:07 UTC

This issue is no longer happening for me when upgrading to 7.4 or 7.5.

Therefore I am closing this ticket.