LD_ASSUME_KERNEL on SLES9, Websphere 6.0

A couple of months ago at work, I struggled to find a solution to an irritating problem that we had with two Websphere 6.0 broker installations on SLES9. The problem itself is kind of hard to explain but I will give it a try.

In our brokers we have a custom installed java node that executes 3red party software using the Exec class found in the libraries of the open source project Ant. The node initiated ok in the broker, it was also able to execute the 3red party program and it began waiting for a return from it, but then the node just halted and was never able to finish. If you used the command top on the command line we saw an additional java process that took a lot of resources and it went away if the broker was stopped. Another strange thing with this issue were that it worked on one broker/machine and not on the other one and both brokers were installed on equivalent systems, or that was what we thought.

After a lots of trails and errors, we found the thing that weren’t equally configured on the two systems; The difference were an environment variable named LD_ASSUME_KERNEL that hold the value 2.4.1 on the failing system and on the working system the value were even set. After I removed the environment variable on the system that didn’t work, it magically began running the node to its end.

After some research of the environment variable I discovered that the LD_ASSUME_KERNEL among other things tells the linker in Linux what libc to use. In my case, setting the LD_ASSUME_KERNEL to the value 2.4.1 made Linux to use an older thread model that were not compliant with the requirements of Websphere Mq Broker.

If you are interested in finding out more about LD_ASSUME_KERNEL you should head over to these two sites.

http://people.redhat.com/drepper/assumekernel.html
http://www.ibm.com/developerworks/linux/library/l-threading.html