Developers have had some time to update their applications to use the new thread model in Linux, but should a piece of software still require an old model, there’s always the tempting environment variable, LD_ASSUME_KERNEL, available to lend a hand.
This environment variable was handy when it was first introduced for handling threading issues in Linux with applications that used an old thread model. However, with new version of Linux, such as Red Hat Enterprise Linux 5.x, it can break other applications that are compliant with the new thread model.
What exactly is this LD_ASSUME_KERNEL variable?
On their developer wiki, Novell answers the question, “What is LD_ASSUME_KERNEL all about?“
The environment variable LD_ASSUME_KERNEL can be set to a value that indicates the kernel OS API version an application is compatible with and is used by the Linux Dynamic Linker/Loader for determining what directory paths to use when loading the Standard C Library (GLIBC or libc.so.6). This is the primary mechanism for dealing with backwards compatibility for applications written for older Linux versions… One of the primary distinguishers of features is the difference between the older LinuxThreads POSIX threading model and the newer threading model NPTL (Native POSIX Thread Library).
So, LD_ASSUME_KERNEL controls which libraries are loaded. Ulrich Drepper explains LD_ASSUME_KERNEL and which libraries and paths each kernel specification loads. To summarize:
- 2.4.20 – newer — New thread model (/lib/tls)
- 2.4.1 – 2.4.19 — Linux Threads (/lib/i686)
- 2.2.5 – 2.4.0 — Old threads (/lib)
What’s the problem?
The problem is that the environment variable can be set on any user and easily forgotten. Until it breaks a newer application that the user must start using which is what happened to me recently.
In my case, a legacy application had long since been removed from the server, but the environment variable had been left to languish in the .bashrc file for the user. It was probably just chance that errors did not appear sooner.
Among other issues, the LD_ASSUME_KERNEL variable has been known to cause problems with Oracle installations on SLES 9, SLES 10, RHEL 4, and RHEL 5, as well as CentOS and other newer Linux releases.
If you have some legacy servers around that will be interacting with newer operating system versions, it may benefit you to take a moment and make sure that LD_ASSUME_KERNEL isn’t hiding out in some user environment. And if you still have an application that requires it, well, I can’t tell you what to do. You may need to get rid of the older application, or stick with an older release of the operating system.