Failing backupscripts

[Klaas D. Eenkhoorn]

Dear All,

Monday i've rebuild my kernel on our hpux11.0 box.
Suddenly the Omniback 5.10 start and stopscripts that i use after the backup behave wierd.

The script to start and stop my database is the same, i call the script simply with the option start, to start and stop, to stop.
During the start operation everything works fine but during stopping the script can't find anny command like su, basename, id etc. that it used before.

I've compaired /etc/profile /etc/PATH and found no differance.

What happend or what can i do !!!

The start/stop scripts have not been changed sinse last week till now.

[Mark Grant · Accepted solution]

Can I suggest that before proceeding, you create a "stop" script that simply does "env". Run this from a dummy backup schedule. Now you can see the "stop" scripts environment in your Omniback log for that session.

Then, post that and the script here :)

[Leif Halvarsson_2]

Hi,
It sounds strange. As a first test you can try to add a line in each script.
in the pre_exec script:
env >/tmp/pre.log

in the pre_exec script:
env >/tmp/post.log

And compare the files after backup.

[Klaas D. Eenkhoorn]

By the way, running them from the commandline gives no poblem.
When i came in these last day's i've used the very same scripts to start the databases and applications after the backup manualy.

Futher i've found out calling the commands explicitly in the script like
/usr/bin/basename seems to work fine.

Probably an Omniback/Dataprotector problem ??

Kl@@S

[Jeroen Peereboom]

Klaas,

i too think it has to do with environment settings, especially $PATH. Did you try the suggestion to execute the 'env' command?
Also check whether $PATH is set explicitly in your script and if it is correct.

If you reaaly think it has to do with your kernel: what changes did you make?

JP.

[Paula J Frazer-Campbell]

Hi

If they run from the command line then the problem is environmental viarables which exits for a login but not when the scripts try to run. Ensure you path fully to all commands that you call in your scripts.

Paula

[Trond Haugen]

This sounds like a very common PATH problem. But the odd ting about it is:
1. You use the same script for starting and stopping.
2. The only change was the building of the new kernel. (?)
In addittion to what has already been suggested, could you please also post the script.

Regards,
Trond

[Klaas D. Eenkhoorn]

Dear All,

My problem is solved, i've added the line "PATH=`/usr/bin/cat /etc/PATH`" to my script after the first line "#!/usr/bin/sh".
Yesterday i've checked the forum group Dataprotector and there were some questions about this behaviour in some old versions of omniback.
All the answers pointed to the fact that omniback does not use a 'default' shell, if you have luck the environment settings are there but it is not guaranteed .

Thanks for all the input !!!

Kl@@s

[Klaas D. Eenkhoorn]

Ok, it works but where did it come from . .
I've rebuild my kernel and the only thing changed was the parameter nflocks, it went from 4096 to 10.000 because of problems with my applications.
nfile is set to 20.000 by the way.

Kl@@s