Bug 1309725 - Missing __pthread_get_minstack symbol in latest glibc
Missing __pthread_get_minstack symbol in latest glibc
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
6.7
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Carlos O'Donell
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-18 09:53 EST by Michal Marciniszyn
Modified: 2016-02-22 20:57 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-22 11:12:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Marciniszyn 2016-02-18 09:53:48 EST
Description of problem:
Vertica database (www.vertica.com) does not run with latest glibc.

Version-Release number of selected component (if applicable):
glibc-2.12-1.166.el6_7.7

How reproducible:
Try start vertica

Steps to Reproduce:
1.
2.
3.

Actual results:
Fails to start with following error:
[ERROR]: /lib64/librt.so.1: symbol __pthread_get_minstack, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference

Expected results:
Vertica starts as expected.

Additional info:
Comment 2 Florian Weimer 2016-02-18 10:05:39 EST
(In reply to Michal Marciniszyn from comment #0)
> Actual results:
> Fails to start with following error:
> [ERROR]: /lib64/librt.so.1: symbol __pthread_get_minstack, version
> GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference

Can you please provide the output of the commands:

  rpm -V glibc.x86_64

  LD_DEBUG=all [command used to start vertica]

This will provide additional diagnostics information.  If you do not want to attach this information to a public bug, please open a support case at:

  https://access.redhat.com/support/
Comment 3 Michael Chapman 2016-02-21 19:21:16 EST
I hit this error message with vsftpd and pam_ldap.

vsftpd links to libpthread (indirectly via libssl and libcom_err). pam_ldap uses librt (indirectly via libnspr4), which then links to libpthread.

If glibc is upgraded while vsftpd is running, and vsftpd isn't restarted (even if it's upgraded its %post scriptlet doesn't do that), then pam_ldap tries to link to librt. This fails since the in-process version of libpthread doesn't have the symbol librt requires; it was added in the newer glibc.

I think this bug could potentially break a lot of long-running software that periodically dlopen's libraries.
Comment 4 Michal Marciniszyn 2016-02-22 07:27:00 EST
We found our problem to be very similar - pam.d + new glibc integration. After further digging in, we found that machine reboot would just fix the issue (which was not done by our QA guys after update and we got report from them of not starting the processes). It is fine by us to close the bug as it can be mitigated by machine/service restart that is anyway desired.
Comment 5 Carlos O'Donell 2016-02-22 09:27:49 EST
(In reply to Michael Chapman from comment #3)
> I hit this error message with vsftpd and pam_ldap.
> 
> vsftpd links to libpthread (indirectly via libssl and libcom_err). pam_ldap
> uses librt (indirectly via libnspr4), which then links to libpthread.
> 
> If glibc is upgraded while vsftpd is running, and vsftpd isn't restarted
> (even if it's upgraded its %post scriptlet doesn't do that), then pam_ldap
> tries to link to librt. This fails since the in-process version of
> libpthread doesn't have the symbol librt requires; it was added in the newer
> glibc.
> 
> I think this bug could potentially break a lot of long-running software that
> periodically dlopen's libraries.

You must restart all services that are using the old libraries after the upgrade. There is simply no way around this issue. This problem would have been seen at some point in the future. Processes that occasionally dlopen libraries will suffer from being unable to load the library at some point in the future and must handle that situation gracefully. It is simply a part of designing robust long-running applications for Linux.

What we could do better is perhaps provide a dnf or yum plugin which warns you that there are processes still running with the old libraries (this is relatively easy to detect e.g. /proc/$PID/map_files/*).
Comment 6 Carlos O'Donell 2016-02-22 11:12:46 EST
(In reply to Michal Marciniszyn from comment #4)
> We found our problem to be very similar - pam.d + new glibc integration.
> After further digging in, we found that machine reboot would just fix the
> issue (which was not done by our QA guys after update and we got report from
> them of not starting the processes). It is fine by us to close the bug as it
> can be mitigated by machine/service restart that is anyway desired.

A machine restart is not required, but the errata does recommend it. It is always suggested that you restart all impacted processes when you upgrade a dependent library.

I am closing this issue as closed/notabug.

Filed this bug for dnf core plugins:
https://bugzilla.redhat.com/show_bug.cgi?id=1310780
Comment 7 Michael Chapman 2016-02-22 20:57:48 EST
(In reply to Carlos O'Donell from comment #6)
> I am closing this issue as closed/notabug.

That's reasonable. However, I would suggest that future errata should recommend a reboot a *little* more strongly than just with a "reboot_suggested" keyword at the bottom. That's very easily missed.

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