Weird Bacula behavior most likely due to /lib/tls

Hello,

During the past several weeks, my production Bacula has exhibited
bizarre behavior such as jobs that get "stuck" for 12 hours and then
complete; two jobs with identical names running at the same time, ...

As best I can tell, this behavior occurs only on recent Linux systems
with recent kernels and /lib/tls loaded.  This new "Native POSIX Threads
Library" overrides the libpthreads library that has been used for years.
In searching the Internet, I have noticed a number of incidences of
other programs that do not run with this new thread library.  

I have now "removed" it from my system, and all bizarre Bacula behavior
seems to have gone away (I don't yet have enough data to be 100% sure,
only time will tell for sure).

If you have /lib/tls on your system and you are running Bacula, you
might want to disable that library.  There are two ways to do so:

1. Rename the library to something different as I did with a command
like:

   mv /lib/tls /lib/tls-broken

This will stop the use of the library on your system for all programs
(except those that are already running). Your best bet is to reboot so
that *all* current usage of that library will stop. The alternative is
to stop and restart all the Bacula daemons.  To the best of my knowledge
no program depends on having /lib/tls present, and I have noticed no
problems here after making the change.

2. The use of the /lib/tls library can also be inhibited on an program
by program basis by defining the environment variable:

   export LD_ASSUME_KERNEL=2.4.1

before starting a program (note, the exact form of the above depends on
your shell).  If this environment variable is defined before the program
starts, the loader will not use the /lib/tls library but rather the old
venerable libpthreads, However, I don't know what other side effects
this may have.


Best regards, Kern

PS:
I'm a bit surprised by the confusing name of the library (tls) -- it
seems that the author is not security conscious, because TLS generally
is associated with SSL and means Transport Layer Security, having
nothing to do with threads.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn