Running RH 7.3, with a bash shell:

I've got a command (binary) called "ipstorxray" that's used inside of a script. From a command line, both the script and the separate command run successfully, but the script errors out if I try to run it with a cron job. In both cases, the command includes the full path to the binary.
Since it does run correctly from the command line, I don't think it's an issue with the command itself, but rather that there's something present in the shell that's not there for the cron job. None of my attempts to feed environment variable definitions into the script has fixed the problem though, so there has to be something else going on that I don't know about. More details below...

The command being issued is:
/usr/local/ipstor/bin/ipstorxray

The error message I'm getting is:
/usr/local/ipstor/bin/ipstorxray: error while loading shared libraries: libfsnxml.so: cannot open shared object file: No such file or directory


I looked for the libfsnxml.so file and found that it does exist at:
/usr/local/ipstor/lib/libfsnxml.so

After a lengthy set of one-at-a-time tests adding various shell environment variable definitions into the script, I got frustrated enough to run an "env" command and dump it's entire output into the beginning of my script. A select few of these env var definitions caused new errors, but the same error message was still there.

My mass adding of environment variable definitions appears to have proven that an environment variable that's present in the shell but unknown to the cron isn't the source of the problem.

What else might be causing the cron-run command to be unable to locate the /usr/local/ipstor/lib/libfsnxml.so file when it seems to have no problem finding it from a command line?

I'm stumped.
Thanks in advance!
WN1

I should also mention that I did define the LD_LIBRARY_PATH in the script. It's set to:

LD_LIBRARY_PATH=/usr/local/ipstor/lib:/usr/local/ipstor/lib

(I've no idea why the same path is in there twice.)

Thanks again.

Is the cron run under your user or another user?
Does the cron user see the same gcc as you? (output from gcc -v)?
Are the PATH env vars the same when you're logged in vs when the cron runs? (not the lib path, but the regular path)

Can you dump env to a file as part of the cron then cross reference that file when dumped as you (I know you said you did something of the sort, though I didn't follow perfectly what you said you did) - a simple "env > foo" or "export > foo" or whatever your shell is happiest with should do the trick.

Whose cron job are you running the job as? Your own, or root's?
If it is root's, try using su to set up the environment as your own, before you execute the command, like this:

I should have included the user information the first time. I'm running as root, in a bash shell, and am using root's cron (crontab -e command).
The the gcc -v command output (the output of which, incidentally, goes to stderr) was the same from the command line and from the script.


What I'd done previously was run the env command from the command line, then manually paste it's output from the screen into the beginning of the script.

I ran an env inside the script as you suggested, and redirected it's output to a file. Most of the environment definitions that I'd placed into the script however, did NOT appear in the redirected output file.

I knew you could define $PATH in a script, but didn't realize that you couldn't define some of the other env vars the same way.

Any suggestions as to how to get a cron-executed script to absorb variables like LD_LIBRARY_PATH ?
Or is there some other way I should be approaching this?

Thanks again.

So, you are executing the command as the user root. Please try running the command (from root's crontab) as I suggested in post #4, which will execute it as yourself. This should resolve any PATH or library problems.

Edit: If you are really running as root, you shouldn't be. It'll cause you big problems later (See the many threads on this board about this). But for testing purposes try:
su - root -c "/path/to/the/script"
/Edit

Setting the cron to run the script by 'su - MYuserID -c /path/to/the/script' tried to work. I set the permissions on the script allow MYuserID to run it but everything else on the system, including the binaries I'm trying to run, are only available to root. (I agree that root shouldn't be running everything, but it's not my server and it's been running that way since it was built, long before I ever touched it.)

Setting the cron to run the script by 'su - root -c /path/to/the/script' worked; probably because it got the right environment variables. For my follow-up questions:
1. What determines the env vars for a command run from (root's) cron? and
2. What determines the env vars for a command run from the cron with an su - root -c command?

I know this is a bit late but...

when run from root's cron, you get the general env vars - those that are defined for all users at login which is different depending on your shell, startup scripts, etc... maybe it's the stuff in /etc/profile? maybe somewhere else?

when you su root to run the command, you get root's env - whatever is in root's .bashrc or .tcshrc (or whatever root uses).

In your script, you *should* be able to set env vars, just make sure you're setting them correctly - export for bash, setenv for tcsh. Also note that setting them in a script only makes those new setting active for that script. As soon as the script finishes, the new settings are gone unless you source the script as opposed to setting it's execute bit & just running it.

Aaah, that's the piece I was missing. I'd been putting the environment variable definitions in the script but expected them to work while the script was running just like any other variable you might create, rather than needing to be exported before they'd work.

Thanks Brian!