DBD::DB2 not finding .so file on system startup

[Larry]

I have a Perl script using DBD::DB2, that runs during system startup on
a Solaris system. The script is working fine during startup on many
machines, except on one machine it fails complaining about a missing
".so" file, with Perl flagging the "use DBD::DB2" line. (I don't have
the exact message since I'm heard about it from a remote sysadmin who
only saw it scroll by on the console). However, if I login as root on
that machine and run the Perl script, it works fine.

I'm thinking there must be some difference in the environment present
at system startup, versus at an interactive shell, which is causing it
to find the .so file when run interactively, but not during startup.
Perhaps it's related to the LD_LIBRARY_PATH variable? I noticed that
the LD_LIBRARY_PATH *is* set for my interactive root shell, but I'm
not sure what it's set to (if anything) during system startup. Perhaps
there a way to re-install DBD::DB2 to fix this?

[Brian Tkatch]

Generally, this would be either not finding the shared library (so) or
not having rights to it. You should try to find out the exact error
message, and then figure out the nature of the error.

B.

[Darin McBride]

Larry wrote:

I have a Perl script using DBD::DB2, that runs during system startup on
a Solaris system. The script is working fine during startup on many
machines, except on one machine it fails complaining about a missing
".so" file, with Perl flagging the "use DBD::DB2" line. (I don't have
the exact message since I'm heard about it from a remote sysadmin who
only saw it scroll by on the console). However, if I login as root on
that machine and run the Perl script, it works fine.

I'm thinking there must be some difference in the environment present
at system startup, versus at an interactive shell, which is causing it
to find the .so file when run interactively, but not during startup.
Perhaps it's related to the LD_LIBRARY_PATH variable? I noticed that
the LD_LIBRARY_PATH *is* set for my interactive root shell, but I'm
not sure what it's set to (if anything) during system startup. Perhaps
there a way to re-install DBD::DB2 to fix this?

DBD::DB2 doesn't load libdb2.so via the LD_LIBRARY_PATH, but by having the
path hardcoded in its own RPATH. So the first thing to come to mind is
that you have DB2 installed on an NFS drive or some other remote partition
that hasn't been mounted yet.

If DB2 is on a locally-mounted partition, then reinstalling the module may
actually help.

[Larry]

Darin McBride wrote:

Larry wrote:

I have a Perl script using DBD::DB2, that runs during system startup on
a Solaris system. The script is working fine during startup on many
machines, except on one machine it fails complaining about a missing
".so" file, with Perl flagging the "use DBD::DB2" line.

DBD::DB2 doesn't load libdb2.so via the LD_LIBRARY_PATH, but by having the
path hardcoded in its own RPATH. So the first thing to come to mind is
that you have DB2 installed on an NFS drive or some other remote partition
that hasn't been mounted yet.

If DB2 is on a locally-mounted partition, then reinstalling the module may
actually help.

We were able to fix it by re-installing the DBD::DB2 module. The best
theory I can come up with now is that the first it was installed, the
DB2_HOME env. var. was not defined. Although I was not the one that
worked on the system in question, I have had experience with installing
DBD::DB2 and forgetting to set DB2_HOME. IIRC, the install does not
complain, and the module will even work in most cases, but such an
installation causes the module to rely on some env. variable(s)
(LD_LIBRARY_PATH, ... ?) in order to work. This would seem to explain
the observed behavior where the module would work in scripts called
from a shell prompt, but not during startup.

What do you think of this explanation? Even though the system is
working now, the higher-ups would like to know why it hapenned
(post-mortem).

[Darin McBride]

Larry wrote:

Darin McBride wrote:

Larry wrote:

> I have a Perl script using DBD::DB2, that runs during system startup on
> a Solaris system. The script is working fine during startup on many
> machines, except on one machine it fails complaining about a missing
> ".so" file, with Perl flagging the "use DBD::DB2" line.

DBD::DB2 doesn't load libdb2.so via the LD_LIBRARY_PATH, but by having
the
path hardcoded in its own RPATH. So the first thing to come to mind is
that you have DB2 installed on an NFS drive or some other remote
partition that hasn't been mounted yet.

If DB2 is on a locally-mounted partition, then reinstalling the module
may actually help.

We were able to fix it by re-installing the DBD::DB2 module. The best
theory I can come up with now is that the first it was installed, the
DB2_HOME env. var. was not defined. Although I was not the one that
worked on the system in question, I have had experience with installing
DBD::DB2 and forgetting to set DB2_HOME. IIRC, the install does not
complain, and the module will even work in most cases, but such an

Actually, as I recall it, unless there's a newer version that "fixes" this,
the module won't install without the DB2_HOME variable set during the "perl
Makefile.PL" phase. In fact, the "perl Makefile.PL" phase won't complete
without this variable set. This makes it kind of annoying to try to get it
to automatically install as part of a CPAN shell.
installation causes the module to rely on some env. variable(s)
(LD_LIBRARY_PATH, ... ?) in order to work. This would seem to explain
the observed behavior where the module would work in scripts called
from a shell prompt, but not during startup.

What do you think of this explanation? Even though the system is
working now, the higher-ups would like to know why it hapenned
(post-mortem).

My guess is that you've upgraded DB2 at some point. You installed DBD::DB2
by compiling against version X, but since then, you've migrated to version
Y, and then uninstalled version X. So DBD::DB2 is still looking for
libdb2.* in version X's directory, but obviously failing. The system
library loader then falls back to looking in your LD_LIBRARY_PATH (or
LIBPATH on AIX or SHLIB_PATH on HP), and has been finding it that way.
Because of DB2's backward-compatability, the new version of libdb2.* works
fine with applications, such as DBD::DB2, which are compiled against the
older version of libdb2.*, so everything seems fine.

This is just a guess, of course, as I have no idea if this machine is old
enough to have had an older version of DB2 on it at some point that you may
have started using DBD::DB2 with.