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
