RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1458841 - yum crashes on update: /lib64/libnsssysinit.so: undefined symbol: PR_GetEnvSecure
Summary: yum crashes on update: /lib64/libnsssysinit.so: undefined symbol: PR_GetEnvSe...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Michal Domonkos
QA Contact: Eva Mrakova
Lucie Vařáková
Depends On:
Blocks: 1256920 1420851 1451275 1461531 1465896 1466368 1469518
TreeView+ depends on / blocked
Reported: 2017-06-05 15:32 UTC by Jiri Jaburek
Modified: 2020-12-14 08:48 UTC (History)
19 users (show)

Fixed In Version: yum-3.4.3-156.el7
Doc Type: Release Note
Doc Text:
Yum no longer crashes in certain _nss_ and _nspr_ update scenario Previously, when the *yum* installer updated a certain combination of _nss_ and _nspr_ package versions, the transaction sometimes terminated prematurely due to a following symbol lookup error: /lib64/libnsssysinit.so: undefined symbol: PR_GetEnvSecure This then caused stale rpm locks. *Yum* has been updated to correctly deal with this particular _nss_ and _nspr_ update scenario. As a result, *yum* does not terminate anymore in the described scenario.
Clone Of:
: 1469518 (view as bug list)
Last Closed: 2018-04-10 15:07:29 UTC
Target Upstream Version:

Attachments (Terms of Use)
NSS workaround, changing nss-sysinit to avoid dependency on PR_GetEnvSecure (2.80 KB, patch)
2017-07-04 21:29 UTC, Kai Engert (:kaie) (inactive account)
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 483074 0 None MERGED Ensure yum cache is ready before update 2020-08-20 09:40:45 UTC
Red Hat Bugzilla 1446093 0 unspecified CLOSED Minor update on OSP8 fails with stack UPDATE_FAILED error: resources.updatedeployment 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1451275 0 high CLOSED Minor upgrades giving error on yum update 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1455224 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 1469526 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2018:0845 0 None None None 2018-04-10 15:07:59 UTC

Internal Links: 1446093 1451275 1455224 1469526

Description Jiri Jaburek 2017-06-05 15:32:04 UTC
(This might be yum/rhsm/nss issue, I'm filing it under yum as it seems the most likely candidate.)

Description of problem:

During a ZStream/EUS yum update from GA (RHEL-7.3, RHEL-7.2, maybe others), the following happens:

  Cleanup    : glibc-common-2.17-157.el7.x86_64                         249/251 
  Cleanup    : glibc-2.17-157.el7.x86_64                                250/251 
  Cleanup    : tzdata-2016g-2.el7.noarch                                251/251 
/usr/bin/python: symbol lookup error: /lib64/libnsssysinit.so: undefined symbol: PR_GetEnvSecure

Afterwards, some yum database seems to be in an inconsistent state, but yum appears to recover on its next invocation:

  BDB2053 Freeing read locks for locker 0x129: 1364/140363639228224

(repeats ~30 times).

Steps to Reproduce:
1. install a minimal RHEL-7.3 GA system from ISO (or other source, but use kickstart which doesn't use 'yum' in %post), make sure to include subscription-manager in the base installation (have it in %packages)
2. register the system using subscription-manager, enable rhel-7-server-rpms, rhel-7-server-optional-rpms - optionally, enable the EUS repos as well
3. do 'yum update' for a full system update, or just 'yum update nss'
4. when asked [y/n], answer 'n'
5. repeat step 3 again, answer 'y'
6. answer 'y' to gpgkey imports
7. observe the error from above

Alternative Steps to Reproduce:
1. have a system with 7.3 GA nss/nspr RPMs
2. register it via subscription-manager, like step 2 before
3. 'rm -rf /var/cache/yum'
4. 'yum makecache fast'
5. 'yum update nss'
6. see the error
7. (to reproduce again, downgrade to RPM versions from 1 and goto 3)

OLD (7.3 GA) RPM versions:

NEW (7.3 ZStream) RPM versions:

I would like to emphasize that to reproduce this, you need to follow the exact steps provided as this issue CANNOT be reproduced:
- if you use just 'yum clean all' instead of 'rm -rf' on the yum cache
- if yum downloads any repo metadata during the upgrade process,
  hence the 'yum makecache fast' or 'n' answer beforehand
- if you upgrade from locally available RPMs instead of RHSM
- if you do any yum operation prior to the update (ie. installing
  an unrelated RPM package)


Based on the above, I have a possible theory of what could be causing the issue.

Yum seems to download

  rhel-7-server-eus-optional-rpms/x86_64/productid  | 2.1 kB  00:00:00
  rhel-7-server-eus-rpms/x86_64/productid           | 2.1 kB  00:00:00
  rhel-7-server-optional-rpms/x86_64/productid      | 2.1 kB  00:00:00
  rhel-7-server-rpms/x86_64/productid               | 2.1 kB  00:00:00

right after Cleanup phases of installed RPMs, but *only* on the second yum invocation; that is one yum invocation *after* repo metadata are downloaded. If nss/nspr is updated during the same yum invocation, the error appears. Hence the magic around 'yum makecache', because if nss/nspr was updated during the same invocation as repo update, the productid bits wouldn't be downloaded (that would happen on next yum run) and nss/nspr would update successfully.

It is possible that the real cause is different, but I'm fairly certain this additional download plays some role in it.

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

Comment 2 Sofer Athlan-Guyot 2017-06-15 09:39:24 UTC
Hi Jiri,

do you have an update on this one, it's start to appear in a lot of RHOS upgrade, OSP8->9 and OSP9->10 are currently known to be affected.

Comment 3 Jiri Jaburek 2017-06-15 09:59:22 UTC
I do not have an update, I can still see the issue.

Comment 6 Sofer Athlan-Guyot 2017-06-22 13:02:09 UTC

we have some more logs for it https://bugzilla.redhat.com/show_bug.cgi?id=1451275#c10, do you need some more info on this one ?


Comment 23 Kai Engert (:kaie) (inactive account) 2017-07-04 21:29:46 UTC
Created attachment 1294350 [details]
NSS workaround, changing nss-sysinit to avoid dependency on PR_GetEnvSecure

Comment 44 Sofer Athlan-Guyot 2017-07-17 11:35:41 UTC

for reference, I'm adding the current upstream review https://review.openstack.org/#/c/483074/ to workaround the problem during RHOS update and cover most of the case during RHOS upgrade (RHOS update should bring RHEL upgrade so we are covered, but we adding a safety net for people "forgetting" to do a RHOS update before RHOS upgrade.)

Comment 55 errata-xmlrpc 2018-04-10 15:07:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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