starting listener running on remote server using script

[Kevin Batter_4]

up until an Oracle upgrade the following part of a script worked
remsh ${PRODUCTION_NODE} -n "su - oracle -c 'lsnrctl start'" >>${LOGFILE} 2>& 1

Now however it just hangs and we have to kill off the remsh to continue the script.According to Oracle this should never have worked but it did !!

Anyone had similar problems and have cured them or does anyone have any other ways of starting a listener on a remote server from within a script

We are running Oracle 8.1.7

Any help appreciated

[A. Clay Stephenson]

I suspect that your fundamental problem is "su - oracle" rather than "su oracle". I know you want to source oracle's .profile to set environment variables but because the .profile almost certainly contains commands like tset, stty, and tabs which expect an interactive environment, the commands fail.

A beeter solution is to use remsh to invoke a script on the remote host which sets and exports all the needed environment variables and then executes lsnrctl.

[Kevin Batter_4]

thanks for the info

Do you happen to know what variables are needed in order to start the listener.

I know I need PATH to the bin dir but what others do I need to putin the script

[Geoff Wild]

You need the su -

Oracle upgrade? you need to check with the dba's and find out what changed...

Try it manually.

remsh PROD

su - oracle

Does that work?

what about 'lsnrctl start'?

Ask them the correct command to start the listener...

Rgds...Geoff

[Kevin Batter_4]

the listener starts it is just that the script just hangs on the remote server and so control does not pass back to the script on the local server so we need to kill off the remsh process and the local script continues on - this means we have to babysit the script whereas before we could just run it and only look at it if there was a problem

[generic_1]

Just an idea. You may want to consider adding ssh and utilizing it instead of remsh because remsh is not secure and sends data accross your network unencrypted. Also ssh is free and downloadable form HP's site. It apears you are using a null password for oracle or remsh as root which is not safe either. There is a free tool called sudo which can provide some logging to su to root and the new versions can run a ldap database so you can centrally control what what commands your users can run and on what servers I hope you got things working again. Best of luck to you.

[A. Clay Stephenson]

I would set the following env variables:

ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=${ORACLE_BASE}/product/8.1.7
TNS_ADMIN=${ORACLE_HOME}/network/admin
export ORACLE_BASE ORACLE_HOME TNS_ADMIN

You may need to export others such as ORACLE_SID or TWO_TASK


I tend to put these commands in a script such as /usr/local/bin/oraenv.sh but make sure that this script contains no exit or return statements

Then both oracle's .profile AND any other batch scripts souce this file using the shell's "." dot operator so that the file is sourced.

e.g.

. /usr/local/bin/oraenv.sh

Now oracle's .profile and everything else "zig" together and any changes can be made in one file.

Plan B.

Surround all interactive commands in oracle's .profile with
if [ -t 0 ]
then
stty ...
tset ...
tabs
fi

so that they are only executed if stdin (-t 0) is a tty device.

I find the common sourced file to be a more elegant approach.

[Geoff Wild]

Ahhh - so control doesn't come back - what about putting it in the background?

remsh ${PRODUCTION_NODE} -n "su - oracle -c 'lsnrctl start &'" >>${LOGFILE} 2>& 1

Do all remsh's hang?

remsh ${PRODUCTION_NODE} date

Rgds...Geoff

[Brian Crabtree]

Jeff,

1. Why not write a script to do this, and call it directly with a su oracle "script" rather than trying to run the lsnrctl directly?

2. Why not just write a monitoring script to run on the system under the oracle cron that would check and see if the listener is available, and starting it as needed?

Thanks,

Brian

[Kevin Batter_4]

cheers for all your replies

the starting of the listener is part of a script that is runing a database refresh using BCVs
so basic order of events are :
bcv establish
shut prod database and listener
bcv split
restart prod database and listener
import bcv
mount filesystems

the script runs on the DR server and does remsh to prod server to do database shutdown and restart.

The only remsh that hangs is the one that restarts the listener so script does not continue to import bcvs,etc to the DR server. Once we kill the listener remsh it will continue and complete ok.

[Geoff Wild]

As Brian mentioned - why not put the shutdown commands in a script on the remote system - then remsh and execute that script instead...

We do something similiar for our backups. bcv splitting and mounting on backup server.

Rgds...Geoff

[Kevin Batter_4]

little bit more info

as per suggestions I have created a script on the prod server that the DR server invokes

To test it I used lsnrctl status - this worked using both

su - oracle -c "lsnrctl status"

and adding oracle variables to begining of script and running su oracle -c "lsnrctl status"

So the feeling here is that it is an issue with running lsnrctl start - got a run of the script coming up this weekend and have gone for the adding variables to script and running su oracle -c lsnrctl start

Will let you know if this makes a difference

[Fred Ruffet]

Did you add patches to OS recently, or changed HP-UX version ? I faced a similar problem upgrading to a more recent version, and found this explenation on an HP site (applicable to versions since 11iv1.6) :

"remsh or rexec may appear hung when you execute certain remote commands, because it waits for the remote command to finish before exiting. This behavior can be changed by adding the -m option to the remsh and rexec lines in /etc/inetd.conf."

You could try to add -m option to remsh line in inetd.conf, restart inetd and try an unmodified version of your script.

Hope this helps,

Fred

[Brian Crabtree]

Why are you stopping the listener? The listener can continue to run while you split off the BCV's without a problem. If the shutdown and startup is working correctly, just use that, and leave the listener running.

Thanks,

Brian

[Kevin Batter_4]

Ok - ran the script as described and once again we had to kill the remsh from the DR server to the prod server that started the listener.

I attach a copy of the script we are using the
first part runs on DR server and invokes second part on Prod server,we will try the -m option on rexec/rlogin this coming weekend but in case there is something that we have missed in the scripts would appreciate any ideas/help

Thanks

[T G Manikandan]

Kevin,

Sorry i am from the beginning,

Did a normal remsh work properly

Did the lsnrctl start work from the local server.

[Geoff Wild · Accepted solution]

Just a thought for the listener, we specify the listener when we stop/start it like so:

remsh ${PRODUCTION_NODE} -n "/bin/su - oracle -c 'lsnrctl start listenerPROD'" | tee ${LOGFILE} >/dev/null 2>&1

Better yet, why not like this:

remsh ${PRODUCTION_NODE} -l oracle -n "lsnrctl start listenerPROD" | tee ${LOGFILE} >/dev/null 2>&1

Rgds...Geoff

[Kevin Batter_4]

TG - yes normal remsh work - earlier in the script we shutdown the Database and the listener using remsh.
The listener starts ok on the prod server it just does not return to the script on the DR server so the DR server script just hangs until we kill the remsh process that is starting the listener up.
Once that is done the script continues on the DR server completing ok

[Volker Borowski]

Hi,

so then do not care about the listener. It has absolutly nothing to do with the datafiles, so to get a consistent copy, it is not needed to stop the listener.
Just shut down the database, do the split and let the listener up and running.
Beside this, to do the login as oracle user as Geoff suggested would be best.

Keep in mind, that you do not need to use any shell at all to re-cycle the listener, since the listener can be controlled remotely (if it is up and runnning) without any shell access .
"lsnrctl" and a proper listener.ora is all you need on a client which should control the target listener [This is why you should configure a password for the listener(!)].

So the last way out would be to do the copy via remsh and re-cycle the listener via network without the shell in case you just want to bounce the listener for whatever reason.

Hope this helps
Volker