Thanks Martin,
The bacula scripts in my initscripts all have the following:
# if /lib/tls exists, force Bacula to use the glibc pthreads instead
if [ -d "/lib/tls" -a $OS = "Linux" -a `uname -r | cut -c1-3` = "2.4" ]
; then
export LD_ASSUME_KERNEL=2.4.19
fi
So yes, it has that build in. I'm not sure what the older machines will
do with older versions of RedHat.
Now the bacula script in /etc/bacula does not seem to do any of the
above, so I guess I should always start and stop with the initscripts.
Funny, though, both are generated from the same source file. You'd
think whatever generates one would have the same safeguard in everything
it creates.
Steve
Martin Simmons wrote:
> The output shows that it is using the libraries from /lib/i686, which are the
> good ones. I think you must have the exports in the init scripts already.
>
> The bad libraries would start with /lib/tls. E.g. look at
> cat /proc/$$/maps
> in the shell (though that will only use libc, not libpthread).
>
> __Martin
>
>
>
>>>>>> On Fri, 24 Aug 2007 17:04:47 -0400, Steve Campbell said:
>>>>>>
>> Thanks Martin,
>>
>> I will post output from the sd daemon below, as I don't know what I am
>> looking for.
>>
>> [EMAIL PROTECTED] bacula]# cat /proc/29179/maps
>> 00111000-00132000 r-xp 00000000 03:06 112227 /lib/i686/libm-2.3.2.so
>> 00132000-00133000 rw-p 00021000 03:06 112227 /lib/i686/libm-2.3.2.so
>> 00133000-00135000 r-xp 00000000 03:06 224522 /lib/libattr.so.1.0.1
>> 00135000-00136000 rw-p 00001000 03:06 224522 /lib/libattr.so.1.0.1
>> 00238000-00244000 r-xp 00000000 03:02 389481 /usr/lib/libz.so.1.1.4
>> 00244000-00246000 rw-p 0000b000 03:02 389481 /usr/lib/libz.so.1.1.4
>> 00323000-0032b000 r-xp 00000000 03:06 224464
>> /lib/libgcc_s-3.2.3-20040701.so .1
>> 0032b000-0032c000 rw-p 00007000 03:06 224464
>> /lib/libgcc_s-3.2.3-20040701.so .1
>> 003cc000-00475000 r-xp 00000000 03:02 389472 /usr/lib/libstdc++.so.5.0.3
>> 00475000-0047a000 rw-p 000a8000 03:02 389472 /usr/lib/libstdc++.so.5.0.3
>> 0047a000-0047f000 rw-p 00000000 00:00 0
>> 008aa000-009de000 r-xp 00000000 03:06 112754 /lib/i686/libc-2.3.2.so
>> 009de000-009e1000 rw-p 00134000 03:06 112754 /lib/i686/libc-2.3.2.so
>> 009e1000-009e4000 rw-p 00000000 00:00 0
>> 00a0f000-00a24000 r-xp 00000000 03:06 224537 /lib/ld-2.3.2.so
>> 00a24000-00a25000 rw-p 00015000 03:06 224537 /lib/ld-2.3.2.so
>> 00b5f000-00b6d000 r-xp 00000000 03:06 112229
>> /lib/i686/libpthread-0.10.so
>> 00b6d000-00b70000 rw-p 0000e000 03:06 112229
>> /lib/i686/libpthread-0.10.so
>> 00b70000-00bb0000 rw-p 00000000 00:00 0
>> 00f3a000-00f3f000 r-xp 00000000 03:06 224524 /lib/libacl.so.1.0.3
>> 00f3f000-00f40000 rw-p 00004000 03:06 224524 /lib/libacl.so.1.0.3
>> 01940000-01941000 ---p 00a00000 00:00 0
>> 01941000-02340000 rwxp 00a01000 00:00 0
>> 08048000-0809c000 r-xp 00000000 03:02 211330 /usr/sbin/bacula-sd
>> 0809c000-0809f000 rw-p 00053000 03:02 211330 /usr/sbin/bacula-sd
>> 0809f000-080a0000 rw-p 00000000 00:00 0
>> 09993000-099b4000 rw-p 00000000 00:00 0
>> b73de000-b75de000 r--p 00000000 03:02 441525
>> /usr/lib/locale/locale-archive
>> b75de000-b75e0000 rw-p 00000000 00:00 0
>> bfff9000-c0000000 rw-p ffffc000 00:00 0
>>
>> I see reference to the libpthreads, but not sure what it's telling me
>> with respect to the kernel variable.
>>
>> I will search the start up for the three daemons, both in my /etc/rc.d
>> scripts and in /etc/bacula and add the export variable to the scripts.
>>
>> Thanks again.
>>
>> Steve
>>
>>
>> Martin Simmons wrote:
>>
>>>>>>>> On Fri, 24 Aug 2007 11:21:28 -0400, Steve Campbell said:
>>>>>>>>
>>>>>>>>
>>>> I still have quite a few servers running the 2.4 kernel. All of these
>>>> are Red Hat clone machines. I do not feel comfortable removing or
>>>> renaming the library, so I have a few questions.I am just getting
>>>> started with Bacula, BTW.
>>>>
>>>> What module uses this that causes the problem? Is it safe to leave the
>>>> library in tact on clients? In other words, Is it the director, storage
>>>> director, file director, or some combination of them that requires this
>>>> to be eliminated?
>>>>
>>>>
>>> All the Bacula daemons are affected by the tls bugs. They will not run
>>> reliably with the tls library in memory, but it is safe to leave the library
>>> on disk.
>>>
>>>
>>>
>>>
>>>> In the event that it is all of them, or at least the file director, and
>>>> I have to do something with my client-only machines, can someone tell me
>>>> exactly how I would set up the workaround mentioned in the manual
>>>> (loader environment variable LD ASSUME KERNEL=2.4.19 ).
>>>>
>>>>
>>> You need a line like this in the scripts that start the daemons:
>>>
>>> export LD_ASSUME_KERNEL=2.4.19
>>>
>>> It is possible that the scripts already do this. You can check which libc a
>>> daemon is using by doing
>>>
>>> cat /proc/$pid/maps
>>>
>>> where $pid is the pid of the daemon.
>>>
>>> __Martin
>>>
>>>
>>>
>>>
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
