Historically, there has been a problem with RPM hanging during updates if glibc changes the condition variable implementation. Code was added to libdb to reinitialization the database environment, including the process-shared condition variable in it, when glibc was updated. This stopped the hangs during RPM updates.

We need to change the condition variable layout once more to fix RHEL-2419 (a bug in glibc with critical customer demand), so this code is relevant again.

However, the code in __os_pthreads_timestamp tries to obtain the timestamp of libpthread and re-initializes the database environment more thoroughly if it changed since the last initialization. This code no longer works because it tries to obtain the timestamp from a loaded libpthread, but RHEL 9 no longer loads that by default even if multiple threads are used.

The change detection was introduced to address this issue:

• Bug 1394862 - libdb: Assumes that internal condition variable layout never changes

There are a couple of ways to fix this:

• Force linking libdb against libpthread. This needs to use the full path because -lpthread is a no-op with glibc 2.34.
• Search for libc.so.6 instead of libpthread.
• Use a fixed path, /usr/lib64/libc.so.6 for 64-bit targets.
• Use dlopen(LIBC_SO, RTLD_LAZY) and dlinfo with RTLD_DI_LINKMAP to get the libc link map, and then use the path in the l_name field.

This issue is less critical in RHEL 9 than in previous RHEL releases because RPM no longer uses Berkeley DB for its database, so we don't expect hangs during updates, and RPM update order should not matter. But libdb could be used by customers (and other RHEL components), and they would still encounter hangs, so I think we need to fix the glibc change detection code.

Due to customer demand, we are backporting the glibc fix to 9.5.z under RHEL-78939, so this libdb fix might be needed there as well.

To verify the change to libdb, you need program that uses the Berkeley DB transactional environment. Run the program under GDB with a breakpoint on __env_check_recreate. The breakpoint should be encountered once on program start after a glibc upgrade/downgrade. Subsequent runs should not hit the breakpoint.