My weekly scripting problem

[Adam Noble]

I've had a problem that has been annoying me for some time. We have tivoli centralised backups and use the dsmc sched tool to schedule when thery run. I have a generic startup script which works on sun servers but not HP's and also works when you simply run from the command line, however not on sytem boot. I think it has something to do with trying to background the process, as if you run it without backgrounding it would just hang there telling you how long till next backup. Anyway here is the string we use within the script any ideas would be appreciated:-

/usr/bin/dsmc schedule 1>/dev/null 2>&1 &

/usr/bin

[Duncan Edmonstone]

Adam,

Does it work if you nohup it?

As in:

nohup /usr/bin/dsmc schedule 1>/dev/null 2>&1 &

Cheers

Duncan

[Dietmar Konermann]

Usually such things get terminated by SIGHUP, unless you use nohup in your script.

However it may also be a problem that the startup scripts don't get a controlling tty from init. Try to run the beast from cron... if that works then this should not be the problem.

And you should redirect stdin also.

So the 1st guess would be:

# nohup /usr/bin/dsmc schedule /dev/null 2>&1 &


Best regards...
Dietmar.

[Adam Noble]

I think you may both be on the right lines with nohup, however still not starting after re-boot. I have also tried running from cron and failing aswell.

[enrico.nic]

I think this problem has something to do with the respawning of the process during system startup.
I would try to put
# /usr/bin/at now + 1 minute < /usr/bin/dsmc schedule 1>/dev/null 2>&1

without the final "backgrounding" &

Hopely this will activate the process at the right time (after boot)

HTH

Enrico

[Duncan Edmonstone]

Adam,

perhaps it's related to the environment...there's a fairly limited environment set up when the startup scripts are called - try typing this at the command prompt:

env | sort > /tmp/env_in_interactive_shell

and then add this to your startup script:

env | sort > /tmp/env_in_startup_shell

Now reboot to allow the script to run in the standard way, and then compare the files using diff

Anything stand out?

Cheers

Duncan

[Duncan Edmonstone]

Also you should check your not getting any errors from the command by sending output to a file, NOT /dev/null :


/usr/bin/dsmc schedule 1>/tmp/dmsc.log 2>&1 &


Cheers

Duncan

[john korterman]

Hi Adam,
Apart from difference of user(?) and environment when starting the script at boot time and running it from the command line, there is perhaps another thing: is the execution depending on something available/being up and running that is perhaps not present at boot time?

Regards,
john k.

[Frank Slootweg]

Add "set -x" at the beginning of the script and "ps -ef | grep dsmc" (or something similar) at the end, and, as others suggested, run the script from at(1) or batch(1), i.e.

echo /path/to/your/script | batch

Next check you e-mail for the output from the job. This should tell you 1) if the script makes it untill the invocation of the dsmc command, 2) whether the dsmc command is started and 3) whether the dsmc command was still running at the end of the script. This should give you a clue as to the cause of the failure.

[Wilfred Chau_1]

I suggest you create a script for your startup command.

/usr/bin/dsmc schedule 1>/tmp/dmsc.log 2>&1 &

And use the system auto startup/shutdown script to call this script. See if it works.

[Donny Jekels]

this is how I fixed your problem.

in the /sbin/init.d/adsm startup file


under the

start)
nohup /usr/adsm/dsmc sched > /var/adm/syslog/adsm.log 2>&1 &

[Justin Willoughby]

We add the following line to our /etc/inittab file so dsmc starts automatically when the system boots and will respawn if it dies unexpectedly, it seems to work pretty well for us. All of our HP systems are setup this way.

adsm::respawn:/opt/tivoli/tsm/client/ba/bin/dsmc sched >/dev/null 2>&1

[Adam Noble]

Thanks guys much appreciated, Donnys string did resolve the problem!