:/etc # uname -a
Linux srvrname 2.6.16.60-0.91.1-xen #1 SMP Tue Oct 18 21:40:25 UTC 2011 i686 i686 i386 GNU/Linux
:/etc # cat SuSE-release
SUSE Linux Enterprise Server 10 (i586)
VERSION = 10
PATCHLEVEL = 4
:/etc # cat novell-release
Novell Open Enterprise Server 2.0.3 (i586)
VERSION = 2.0.3
PATCHLEVEL = 3
BUILD
We’re using Syncsort Backup Express 3.21, but the client has a bug where, when trying to run it’s “detect” command, it won’t run because it’s own libraries are not in the path. The official fix is to issue this two commands:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/opt/backupexpress/lib
export LD_LIBRARY_PATH
(This doesn’t survive a reboot, but I also found I could acheive the same result by simply appending “/opt/backupexpress/lib/” to the end of the /etc/ld.so.conf file and running ldconfig, which does survive a reboot. Again, on all other servers it’s not an issue)
Sure enough, this command enables their detect command to run and report on attached SCSI devices.
On most of our SLES/OES servers, setting the library path is not an issue, but on this one box, it apparently completely replaces all other library paths! Nothing in X11 works after that. Trying to run yast2 results in screen after screen of "couldn’t load or find library such and such errors. I have to issue a “unset /opt/backupexpress/lib” command to remove it from the path, then X works again.
Before going into this let me point out a few things that MAY make a
difference.
First, a variable is not global in scope. From the time it is set it
applies only to the single environment in which it was set, and not even
to child environments (sub-shells, etc.) unless exported (which you are
doing). As a result when you write something like setting this messes
up all kinds of things like X and every other application, it makes me
think you’ve set this path somewhere that affects all subsequent
programs (usually not a good idea) instead of in a single startup script
where it can apply to the needed application (like Backup Express).
Normally additions to variables like LD_LIBRARY_PATH or LD_PRELOAD are
set in the script which actually calls the binaries requiring the new
libraries; not always, of course, but in cases where the new libraries
are not system-specific, this is how it should work. Adding more
libraries to somewhere that causes every application in the world to see
this new set of libraries wastes time at best (one more place to check
for stuff) and causes problems like you are seeing in more severe cases.
Next, how do you know it is replacing? I am guessing that it is not
replacing anything, but that LD_LIBRARY_PATH is not set at the time that
you are “appending” to it (normally this variable is not needed for
things since the system has its own location for global things).
Appending to something that is not set at all means your LD_LIBRARY_PATH
will end up looking like ‘:/opt/backupexpress/lib/’ and then have more,
potentially, after that. This is another reason that these types of
variable declarations/instantiations should happen in the startup script
of the application which requires these types of modifications to work.
Anytime you set something explicitly like this, though, any application
that is C-based will look at the variable before checking the system’s
collection of libraries and try to load what it finds, and any
conflicting symbols will cause what you are seeing.
In summary: do not set this globally unless it applies globally (this
definitely does not) and you know it should be applied globally. Feel
free to verify the value of LD_LIBRARY_PATH before you are setting it
with something like an echo to a file, but I’d be willing to bet this is
all a configuration issue. I’m a little surprised that Backup Express
does not ship with a script that correctly sets the LD_LIBRARY_PATH
variable for its own purposes like every other application does.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
To make this lib path “stick”, you should create /etc/ld.so.conf.d/backex.conf with the any lib paths for Backup Express. Looks like you only have one:
/opt/backupexpress/lib
Then run the command ldconfig -v. Linux uses /etc/ld.so.conf, or more precisely ld.so.cache which gets updated from the ldconfig command, to locate libraries. Anything in /etc/ld.so.conf.d/ is included in the main ld.so.conf file as you can see. The LD_LIBRARY_PATH environment var is also used to specify library paths, but as the other poster mentioned, thats only set for your current shell session.
Just want to note, I ran the export command because that is expressly what Backup Express says to do in their TID, regarding this issue. (They acknowledge this)
However, this workaround this doesn’t seem to affect any other servers in the same, but just this one (which I didn’t set up)
I know that this env setting on this server caused issues because once set, I couldn’t run anything in X on it, I got tons of library errors.
If I then ran an “unset LD_LIBRARY_PATH” command, everything returned back to normal.
I also checked against other servers that I have never done this with, and no LD_LIBRARY_PATH appeared in their env, so that appears to be the default.
In any case, I think I found my own workaround. This detect command failed due to only a single library file it couldn’t find (libcmapi.so); I did a find on the entire file system and no other instance of that lib file existed but the one, so I put a softlink to it inside another library directory already on the path (/usr/lib).
Now I can run the command, and, X isn’t borked either.
Thanks ashbyj, I’ll remember this tidbit for future reference, but I think I found another workaround for this issue that seems to be working. (see above)
AFAIK, it’s only this “detect” command of theirs that doesn’t work right, so I should be okay.