[Rear-users] Re: Problems with multiple libraries ...
Schlomo Schapiro
schlomo at schapiro.org
Mon Apr 20 18:58:13 CEST 2009
Hi Peter,
now we come closer to the actual problem. It seems to me that the
problem is a very strange setup of your systems, if you provide the
content of $PATH, $LD_LIBRARY_PATH and /etc/ld.so.conf* we will probably
see it clearly.
AFAIK (based on several customer locations) TSM client is installed into
/opt/tivoli/tsm/client with maybe a few symlinks into /usr/sbin (e.g.
dsmc). In your case apparently
- there are more symlinks of TSM components and especially libraries
- you have some TSM directories in the PATH which are not normally in
the path
- ? ( I am not a prophet)
The reason why I suspect this is how ReaR collects the files:
1) Everything in COPY_AS_IS is copied over with tar without looking at
the files
2) Everything in PROGS gets analyzed with ldd to collect required
libraries (adds to LIBS and LIBS64) and copied over to /bin in the ReaR
rescue image
3) Everything in LIBS and LIBS64 gets analyzed with ldd for dependancies
(adds to LIBS and LIBS64) and copied over to /lib in the ReaR rescue image
Therefore, if ReaR fails on copying '/usr/sbin/rsct/lib/libct_cu.so'
then this library must have been a depenancy of something in PROGS or
LIBS. BTW, this path is IMHO more than strange and totally against FHS!
(Meaning, if ReaR brakes on a broken system ...)
The fact that we collapse all bin and lib paths to a single path in the
rescue media is for simplicity mostly and to make our live easier
because we don't care where a distribution will put a binary (as long as
it is in $PATH), in the end it will be in /bin on the rescue media. It
seems to me that if you have problems with libraries in different paths
you should better solve that problem than fix ReaR to do something which
normally is not required in any case.
> ./usr/lib/libct_cu.so
> ./usr/sbin/rsct/lib/libct_cu.so
> ./opt/tivoli/tsm/client/api/bin/libct_cu.so
Assuming that all 3 files are the same you should remove all but one
(e.g. the one in /lib). Alternatively fix your ld.so.conf and $PATH so
that you don't need this library in so many places. For example it would
be better to adjust ld.so.conf (or place a file in /etc/ld.so.conf.d/)
to include /opt/tivoli/tsm/client/api/bin or /usr/sbin/rsct/lib.
The reason why I am insisting is that you are the first user to report a
problem here and that the problem did not appear when I was there (if we
talk about the same there...) which leads me to believe that this issue
is something very specific to your setup. For example, ReaR assumes that
the full version is the library itself and the names without version (or
shorter version strings) are symlinks. This is what ldconfig usually
makes. I really would like to understand why this issue comes up only in
your environment and not with all TSM users.
BTW, I looked into cp to understand when it brings the same file message
(see
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy.c?h=COREUTILS-5_92
for example). As you can see there this case is extremely complicated
and the amount of checks cp does is amazing. Basically it uses a series
of stat calls to decide the same file questions (and of course reads
symlinks).
As far as I can tell the problem is really that you have a library and a
symlink to it and that they have the *same* name and that the symlink is
found before the actual library (according to ld.so.conf).
I would like to really provide a proper fix for the situation and not
simply hack around in ReaR. The least we have to do in ReaR is make
another stat call to see if the destination that exists already is a
file or a symlink and provide different error messages. We also should
compare only if it is a file and not a symlink. If it is a symlink then
one can simply allow the copy and replace the symlink by the proper
file. If it is not a symlink then cp probably will not fail in any case
because it seems that it fails specifically for the
symlink-named-as-the-library case.
Maybe something like this will be more suited:
39 LibCopyTo() {
40 TARGET="$1" ; shift
41 test -d "$TARGET" || Error "[LibCopyTo] Target $TARGET not a
directory"
42 for k in "$@" ; do
43 test -z "$k" && continue # ignore blanks
44 test -r "$k" || Error "[LibCopyTo] Source $k is not readable"
>>>>>> test -L "$TARGET/$(basename "$k")" && rm -f "$TARGET/$(basename "$k")"
45 cp -v -a "$k" "$TARGET" || Error "[LipCopyTo] Could not copy
'$k' to '$TARGET'"
46 test ! -L "$TARGET/$(basename "$k")" && strip -s
"$TARGET/$(basename "$k")"
47 done
48 true
49 }
What do you think? Maybe you can test it? (Much cheaper, just one stat
call which will be re-used by the cp in the next line).
Regards,
Schlomo
PS: What happened to Ubuntu :-)
Peter Eckhardt wrote:
> Hello Schlomo,
>
> 1.) Problem with library and symlink
> ====================================
>
> ohne COPY_AS_IS_TSM --->
>
>
> # sample local configuration
>
> # Create ReaR rescue media as ISO image
> OUTPUT=ISO
>
> # optionally set your backup software
> BACKUP=TSM
>
> # the following is required on older VMware VMs
> # MODULES_LOAD=( vmxnet )
>
>
> usr/sbin/rsct/lib/libct_tr.so /usr/sbin/rsct/lib/libha_gs_r.so
> cp: `/usr/sbin/rsct/lib/libct_cu.so' and
> `/tmp/rear.5342/rootfs/lib/libct_cu.so' are the same file
> 2009-04-20 10:50:40 ERROR [LipCopyTo] Could not copy
> '/usr/sbin/rsct/lib/libct_cu.so' to '/tmp/rear.5342/rootfs/lib'
>
> mit COPY_AS_IS_TSM --->
>
> # sample local configuration
>
> # Create ReaR rescue media as ISO image
> OUTPUT=ISO
>
> # optionally set your backup software
> BACKUP=TSM
> COPY_AS_IS_TSM=( /etc/adsm/TSM.PWD /opt/tivoli/tsm/client )
>
> # the following is required on older VMware VMs
> # MODULES_LOAD=( vmxnet )
>
>
> /lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.7
> /usr/sbin/rsct/lib/libct_cu.so /usr/sbin/rsct/lib/libct_tr.so
> /usr/sbin/rsct/lib/libha_gs_r.so
> cp: `/usr/sbin/rsct/lib/libct_cu.so' and
> `/tmp/rear.8919/rootfs/lib/libct_cu.so' are the same file
> 2009-04-20 10:55:27 ERROR [LipCopyTo] Could not copy
> '/usr/sbin/rsct/lib/libct_cu.so' to '/tmp/rear.8919/rootfs/lib'
>
> ---------------------
>
> machine:/ # find . -name "*libct_cu.so"
> ./tmp/rear.5342/rootfs/lib/libct_cu.so
> ./tmp/rear.5342/rootfs/opt/tivoli/tsm/client/api/bin/libct_cu.so
> ./tmp/rear.8919/rootfs/lib/libct_cu.so
> ./tmp/rear.8919/rootfs/opt/tivoli/tsm/client/api/bin/libct_cu.so
> ./usr/lib/libct_cu.so
> ./usr/sbin/rsct/lib/libct_cu.so
> ./opt/tivoli/tsm/client/api/bin/libct_cu.so
>
> s96sanpns00:/ # ls -l /usr/lib/libct_cu.so
> lrwxrwxrwx 1 bin bin 30 Mar 12 10:38 /usr/lib/libct_cu.so ->
> /usr/sbin/rsct/lib/libct_cu.so
>
> ls -l /usr/sbin/rsct/lib/libct_cu.so
> -r--r--r-- 1 bin bin 595453 May 20 2008 /usr/sbin/rsct/lib/libct_cu.so
>
> ls -l /opt/tivoli/tsm/client/api/bin/libct_cu.so
> -r-xr-xr-x 1 root bin 334774 Nov 28 16:19
> /opt/tivoli/tsm/client/api/bin/libct_cu.so
>
> ldd /usr/bin/dsmc
> linux-gate.so.1 => (0xffffe000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f64000)
> libpthread.so.0 => /lib/libpthread.so.0 (0xf7f4e000)
> libdl.so.2 => /lib/libdl.so.2 (0xf7f4a000)
> libgpfs.so => /usr/lib/libgpfs.so (0xf7f41000)
> libdmapi.so => /usr/lib/libdmapi.so (0xf7f3a000)
> librt.so.1 => /lib/librt.so.1 (0xf7f31000)
> libha_gs_r.so => /usr/lib/libha_gs_r.so (0xf7f08000)
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7e4c000)
> libm.so.6 => /lib/libm.so.6 (0xf7e27000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7e1c000)
> libc.so.6 => /lib/libc.so.6 (0xf7cef000)
> /lib/ld-linux.so.2 (0xf7fa6000)
> libct_cu.so => /usr/lib/libct_cu.so (0xf7c89000)
> libct_tr.so => /usr/lib/libct_tr.so (0xf7c7e000)
>
> In this case problem is the symlink. Fisrt the "contents" of the symlink
> is copied
>
> 2009-04-20 10:55:27 Libraries(32): /lib/libnss_dns-2.4.so
> /lib/libnss_dns.so.2 /lib/libnss_files-2.4.so /lib/libnss_files.so.2
> /lib/libgcc_s.so.1 /lib/libresolv-2.4.so /lib/libresolv.so.2
> /lib/ld-2.4.so /lib/ld-linux.so.2 /lib/libc-2.4.so /lib/libc.so.6
> /lib/libcrypt-2.4.so /lib/libcrypt.so.1 /lib/libdl-2.4.so
> /lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
> /lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
> /lib/librt.so.1 /usr/lib/../../opt/tivoli/tsm/client/api/bin/libApiDS.so
> /usr/lib/../../opt/tivoli/tsm/client/api/bin/libxerces-c1_6_0.so
> /usr/lib/../../opt/tivoli/tsm/client/api/bin/libxmlutil-5.5.1.0.so
> /usr/lib/libApiDS.so /usr/lib/libct_cu.so /usr/lib/libct_tr.so
> /usr/lib/libdmapi.so /usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
> /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
> /usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.5
> /usr/lib/libstdc++.so.5.0.7 /usr/lib/libtsm551xerces-c1_6_0.so
> /usr/lib/libxmlutil-5.5.1.0.so /usr/sbin/rsct/lib/libct_cu.so
> /usr/sbin/rsct/lib/libct_tr.so /usr/sbin/rsct/lib/libha_gs_r.so
> /lib/ld-2.4.so /lib/ld-linux.so.2 /lib/libc-2.4.so /lib/libc.so.6
> /lib/libcrypt-2.4.so /lib/libcrypt.so.1 /lib/libdl-2.4.so
> /lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
> /lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
> /lib/librt.so.1 /usr/lib/libct_cu.so /usr/lib/libct_tr.so
> /usr/lib/libdmapi.so /usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
> /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.7
> /usr/sbin/rsct/lib/libct_cu.so /usr/sbin/rsct/lib/libct_tr.so
> /usr/sbin/rsct/lib/libha_gs_r.so
> cp: `/usr/sbin/rsct/lib/libct_cu.so' and
> `/tmp/rear.8919/rootfs/lib/libct_cu.so' are the same file
> 2009-04-20 10:55:27 ERROR [LipCopyTo] Could not copy
> '/usr/sbin/rsct/lib/libct_cu.so' to '/tmp/rear.8919/rootfs/lib'
>
> First /usr/lib/libct_cu.so is copied then /usr/sbin/rsct/lib/libct_cu.so
> which fails because the symlink was copied.
>
> 2.) Same problem different results
> ===================================
>
> # sample local configuration
>
> # Create ReaR rescue media as ISO image
> OUTPUT=ISO
>
> # optionally set your backup software
> BACKUP=TSM
> COPY_AS_IS_TSM=( /etc/adsm/TSM.PWD /opt/tivoli/tsm/client )
> # the following is required on older VMware VMs
> # MODULES_LOAD=( vmxnet )
>
>
> 2009-04-20 11:29:35 Libraries(32): /lib/libnss_dns-2.4.so
> /lib/libnss_dns.so.2 /lib/libnss_files-2.4.so /lib/libnss_files.so.2
> /lib/libgcc_s.so.1 /lib/libresolv-2.4.so /lib/libresolv.so.2
> /lib/ld-2.4.so /lib/ld-linux.so.2 /lib/libc-2.4.so /lib/libc.so.6
> /lib/libcrypt-2.4.so /lib/libcrypt.so.1 /lib/libdl-2.4.so
> /lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
> /lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
> /lib/librt.so.1 /usr/lib/../../opt/tivoli/tsm/client/api/bin/libApiDS.so
> /usr/lib/../../opt/tivoli/tsm/client/api/bin/libxerces-c1_6_0.so
> /usr/lib/../../opt/tivoli/tsm/client/api/bin/libxmlutil-5.5.1.0.so
> /usr/lib/libApiDS.so /usr/lib/libct_cu.so /usr/lib/libdmapi.so
> /usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
> /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
> /usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.5
> /usr/lib/libstdc++.so.5.0.7 /usr/lib/libtsm551xerces-c1_6_0.so
> /usr/lib/libxmlutil-5.5.1.0.so /lib/ld-2.4.so /lib/ld-linux.so.2
> /lib/libc-2.4.so /lib/libc.so.6 /lib/libcrypt-2.4.so /lib/libcrypt.so.1
> /lib/libdl-2.4.so /lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so
> /lib/libm.so.6 /lib/libpthread-2.4.so /lib/libpthread.so.0
> /lib/librt-2.4.so /lib/librt.so.1
> /opt/tivoli/tsm/client/api/bin/libgpfs.so /usr/lib/libct_cu.so
> /usr/lib/libdmapi.so /usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
> /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.7
> cp: `/opt/tivoli/tsm/client/api/bin/libgpfs.so' and
> `/tmp/rear.16149/rootfs/lib/libgpfs.so' are the same file
> 2009-04-20 11:29:35 ERROR [LipCopyTo] Could not copy
> '/opt/tivoli/tsm/client/api/bin/libgpfs.so' to '/tmp/rear.16149/rootfs/lib'
>
> machine2:/ # find . -name "*libgpfs.so"
> ./tmp/rear.16149/rootfs/lib/libgpfs.so
> ./tmp/rear.16149/rootfs/opt/tivoli/tsm/client/api/bin/libgpfs.so
> ./opt/tivoli/tsm/client/api/bin/libgpfs.so
> ./usr/lib/libgpfs.so
>
> machine2:/ # ldd /usr/bin/dsmc
> linux-gate.so.1 => (0xffffe000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f2f000)
> libpthread.so.0 => /lib/libpthread.so.0 (0xf7f19000)
> libdl.so.2 => /lib/libdl.so.2 (0xf7f15000)
> libgpfs.so => /usr/lib/libgpfs.so (0xf7f0c000)
> libdmapi.so => /usr/lib/libdmapi.so (0xf7f05000)
> librt.so.1 => /lib/librt.so.1 (0xf7efc000)
> libha_gs_r.so => /usr/lib/libha_gs_r.so (0xf7edd000)
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7e21000)
> libm.so.6 => /lib/libm.so.6 (0xf7dfc000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7df1000)
> libc.so.6 => /lib/libc.so.6 (0xf7cc4000)
> /lib/ld-linux.so.2 (0xf7f70000)
> libct_cu.so => /usr/lib/libct_cu.so (0xf7c7a000)
>
> ls -l /opt/tivoli/tsm/client/api/bin/libgpfs.so
> -r-xr-xr-x 1 root bin 39165 Nov 28 16:19
> /opt/tivoli/tsm/client/api/bin/libgpfs.so .
>
>
> ls -l /usr/lib/libgpfs.so
> lrwxrwxrwx 1 root root 41 Mar 5 07:20 /usr/lib/libgpfs.so ->
> /opt/tivoli/tsm/client/api/bin/libgpfs.so
>
> First /usr/lib/libgpfs.so is copied then
> /opt/tivoli/tsm/client/api/bin/libgpfs.so .
>
>
>
> Hope that helps a bit
> Peter
>
>
>
> Quoting Schlomo Schapiro <schlomo at schapiro.org>:
>
>> Hi Peter,
>>
>> that is a much better explanation, let me ask you a few questions:
>>
>> How would the example of same-named but different libraries work on the
>> source system? If such libraries are installed in different directories
>> that are part of the library loader path (/etc/ld.so.conf) then AFAIK
>> the loader will in any case only take the first and ignore the second. I
>> can imagine that it works if some software brings private libraries and
>> sets LD_LIBRARY_PATH, thus forcing the loader to consider the private
>> libraries first. But in that case ReaR would not pick up these libraries
>> in any case because ReaR can find only those libraries that ldd gives us
>> which are only those libraries that are mentioned in ld.so.conf.
>>
>> I already encountered such software (e.g. Galaxy) and the solution was
>> to copy all the software with the private libraries through COPY_AS_IS
>> which does not resolve any libraries.
>>
>> To better understand your actual problem, could you please tell us more
>> about it with specific examples where you had this problem? With your
>> modification I would expect ReaR to fail on that system in any case.
>>
>> Regards,
>> Schlomo
>>
>> PS: What I am trying to say is that I am not yet convinced that we are
>> solving the right problem with this patch.
>>
>> Peter Eckhardt wrote:
>>> Hello,
>>>
>>> it took a bit to answer. Somehow holidays were more important than
>>> rear :-)
>>>
>>> ReaR has a generic problem if a libary with the same name exists in
>>> two different directories. A situation which appears quite regulary if
>>> an admin creates compatibility links or two packages bring the same
>>> library but decide to have them in different directories.
>>> If such a situation arises it makes the creation of the ReaR ISO fail
>>> (without error message) in the LibCopyTo function. Problem is the cp
>>> command which can't (and shouldn't) overwrite an existing file.
>>> Overwriting may lead to the problem that in case two libaries with the
>>> same name but different version or different functionality exists only
>>> the last one copied will survive. In case of overwriting (i.e the cp
>>> command line gets fixed) the cp command will succeed, the creation of
>>> the ReaR iso too, but the restore form the iso may fail later due to
>>> missing symbols in the library. So i personally prefer an abort of the
>>> cp than just a silent overwrite.
>>>
>>> Thats the reason why i added the cmp command in the proposed fix. It
>>> will only copy if the target does not exist or if target and source
>>> aren't identical (then the cp will fail).
>>>
>>>
>>> test -r "$k" || Error .....
>>> if ! cmp "$TARGET/${basename $k}" "$k"
>>> then
>>> cp -v -a ......
>>> else
>>> Error "[LibCopyTo] Library $k exists more than one. Contents
>>> differs. Aborted"
>>> fi
>>> test ! -L ......
>>>
>>> Brgds
>>> Peter
>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>>
>> Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Rear-users mailing list
>> Rear-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rear-users
>>
>
>
>
More information about the rear-users
mailing list