Control SA as start up

[david_252]

Hi team:

We are going to have control Sa s/w on our 10.20 boxes and would like to have some inputs on making it as a startup script with no hup. Please send some inputs.

Thanks
David.

[Jeff Schussele · Accepted solution]

Hi David,

We run it as well on our 11.0 systems.
I've already built tested & deployed these scripts.
When I get to work in a couple of hours, I'll show you how we do it.

Stand by,
Jeff

[Jeff Schussele]

Hi (again) David,

As promised here's the Control-SA conf file that resides in /etc/rc.config.d
It's primary function is to toggle the autostart on/off.

#!/sbin/sh
# @(#)ctsa config B.02.20 09/18/97
#
# Control-SA Agent (CTSA) startup control
#
# To execute the Control-SA agent automatically at boot time, ensure the
# CTSA_START variable below is set to 1. Any other value will disable
# Control-SA agent execution at bootup. For values other than 1, Control-SA age
nt can be
# started after bootup is complete with the /systools/ctsa/control-sa/scripts/st
art-ctsa script.
#
# To start up Control-SA with special options, change the
# CTSA_START_COMMAND from its default value of "/systools/ctsa/control-sa/script
s/start_ctsa"
# to the desired value.
#
# WARNING: BE SURE TO MAINTAIN "" AROUND THE START COMMAND STRING
# OR THE SCRIPT WILL NOT WORK!!!
#
# This file originally has CTSA_START set to 1.
#
CTSA_START=1
CTSA_START_COMMAND="su - hpuxp -c /systools/ctsa/control-sa/scripts/start-ctsa"

Attached is the start/stop script from /sbin/init.d
We link it to S920ctsa in rc3.d & to K080ctsa in rc2.d
But you can use whatever value you desire. We put it high so it's one of the last scripts to run.

We even took the further step & swpackaged the Control-SA install itself - mainly for version control. But for ease of installation as well.
I won't even start to describe just how difficult that process was.
And lucky me, I get to do it all over again - I just got the new version, 3.1.01, in & am in progress swpackaging it at this time. Should go quicker this time....I hope.

HTH,
Jeff

[david_252]

Jeff:

I have a question for you on control sa. I see three processes p_ctsco and p_ctssu and p_ctscd
The p_ctscd process seems to runaway always. Have you seen this issue??? even if i try to kill that it starts up again. finally when i did kill -9 it is gone. Can you advise please???

Thanks
David.

[Jeff Schussele]

Hi (again) David,

Well, p_ctscd is the notification server (CD) for the Control-SA agent. It and the transaction server (CS) will normally not be started until the agent makes contact with the ESS server.
I'm not sure why it's running away on you, but might speculate that there is probably a Control-SA patch that needs to be applied.
Check with your BMC rep & ask what patch(es) have been issued since this version came out & see if you've applied them to your installation.
My p_ctscd does not runaway, but I'm current on Control-SA patches.

HTH,
Jeff

[david_252]

Hi (again) Jeff:

I noticed that when i stopped the control-sa scripts it takes about 40 seconds to stop them. How did you handle this in your scripts??? Just curious??

Thanks
David.

[Jeff Schussele]

Hi David,

If you look at my /sbin/init.d/ script again, you'll see that all I do is

su - hpuxp -c "/systools/ctsa/control-sa/scripts/stop-ctsa"

Which just runs their stop script as the appropriate user. I don't wait for anything & I haven't had a problem with the Control-SA processes stopping. But you're right they do take a little time to shut down. If you're concerned, you can just put an appropriate length sleep statement in there to cover the lag.

Rgds,
Jeff

[david_252]

Hi Jeff:

Can you give me the part of postinstall (i suppose) where you add the ctsa id. Also do you set a passwd first 'coz when you do useradd it locks the a/c until the passwd is changed. Can you help?

Thanks

David.

[Jeff Schussele]

Hi (again) David,

Attached is my postinstall (you were correct) script where I check for the presence of the user & the appropriate UID, GID & home dir & change them if not correct. It also adds the group & user if they don't exist.
It's last task is to start the CTSA install script.
Note that all the vars in the script are defined in the autoinst.ini file.

HTH,
Jeff

[david_252]

Jeff:

A strange issue here. After reboot, the ctsa processes are not staying up. But when i go back and start them again, it stays up. I can't think of anything else except may be move the ctsa from rc3.d to rc4.d and try to reboot again. Did you encounter this issue? Any thoughts??

Thanks
David.

[Steven E. Protter]

Add this to your startup script.

env /tmp/sa.txt

compare that after a boot the root env command after startup.

Modify the script to correct discrepencies.

SEP

[Steven E. Protter]

David,

I don't think your last suggestion will make a difference.

rc scripts pretty much run in the same environment, no matter the run level.

The only exception to that statement is if there is some dependency not being met, ie some deamon that needs to be running and isn't in your current starting "lineup"

SEP

[david_252]

Steve:

You were right on target. Moving the startup from rc3.d to rc4.d did not help. But the fact is we are using the same script in /etc/rc.config.d/ctsa and /sbin/init.d. I am not sure why the process does not stay UP on reboot, whereas it is able to if i manually start it using /sbin/init.d/ctsa start. Regarding you env test can you be more specific?

Thanks
David.

[Steven E. Protter]

Deep apologies for the delay. I'm in hyper mode of a production server rollout.

On a working 10.20 server add this line to the startup script.

/usr/bin/env > /tmp/notworking.txt

After startup.

/usr/bin/env > /tmp/working.txt

use ftp or whateve to put the two files on the same machine.

diff /tmp/working.txt /tmp/notworking.txt

That will show the difference in the environment between the startup/rc script and a regular shell environment.

If you assign the variables missing in the notworking.txt data to the startup script, you should get it to run.


Another helpful hint is to do this to the startup script.

/ias/product/1.0.2/6iserver/reports60_server start" >> $LOGFILE

This example is for oracle, but it routes all of the output from the script into a text file for analysis after the fact. Just set LOGFILE variable.

I believe the command set -x in the startup script will give you even more copious diagnostic information.

Sorry for the delay, let me know if I can help.



SEP

[david_252]

Jeff:

I am doing Control SA on the 11.0 box (swpackage and push on all the boxes). we are using home-grown scripts for adding and deleting users and i suppose we have to use it with Control SA for adding login id's and removing them. Do you see any issue with this etup (we run NIS)?

Thanks

David