RE: KSH Scripting Questions

From: Kevin Lange <kgel_at_ppoone.com>
Date: Mon, 10 Dec 2001 12:52:37 -0800
Message-ID: <F001.003D93C2.20011210123531@fatcity.com>

That is prety much phase 2. Phase 1 is the simplistic view. The archive process program starts , creates a file, starts the monitor ... does the rsh ....deletes the file.

When the monitor starts ... it sleeps a proscribed time ... then checks the file existance. If its there, it sleeps again (for a specific amount of times). If the file is still there after x times, the monitor e-mails.

My trouble is , the main process does not seem to be deleteing its files. I am chaning now on what kind of error messages they are getting.

Thanks

-----Original Message-----
Sent: Monday, December 10, 2001 2:16 PM
To: Multiple recipients of list ORACLE-L

Yeah, I did that a fair amount, too. It depends on whether you're going to do all your monitoring from your script, or whether you're going to go and fire off a zillion monitors and let them fly on their own. If you're doing it all in the same script, then it becomes easy... for machine in `x y z` do all these things synchronously. If you fire them off until X monitors are running or fire them all off at once to run asynchronously, you need another method to determine what fails and what doesn't. I found that the best way of doing it is to have a <unique-log-file-name> that gets touched when the rcp/rsh happens and removed when the rcp/rsh terminates, then have another process that sits in a 30 second wait loop to see if any of these processes have been running over Y minutes. Of course, if you want to customize the crap out of it (I always did) you could have the time allowable to be per type or by machine (or both)... for example, if you just want to see if the listener is up, that is going to take much less time to test than if you're running a backup. Anyway, I suspect that you're going to find that nohup is your friend, but that you're not going to want to keep a log of it, because if you're doing what I think you're doing, it's going to get very big very fast.

OH. One thing. If you going to have a master process and a waiter in a loop and you're going to run this on multiple machines, you may want to set up a process on a different machine to monitor your master on your main machine, and, if it goes down, copy over all the log files and start the monitoring from the remote machine. Then keep checking to see if you're main machine comes back, and, if so, copy over the logs, quit processing and let your master machine have the reins again.

HTH,
Bambi.

-----Original Message-----
Sent: Monday, December 10, 2001 1:31 PM
To: Multiple recipients of list ORACLE-L

The monitors are independent. They are used to verify that rcp/rsh programs work correctly. We have been having troubles where rcp and rsh programs fail on one end and never return with a good or bad return code. We wanted the monitor to tell us if the program did not come back in a reasonable times. It does this by checking the existance of a file that is created at the begining of the process and deleting the file at the end of the process.

-----Original Message-----
Sent: Monday, December 10, 2001 11:35 AM To: Multiple recipients of list ORACLE-L

Kevin --

Is your program supposed to find all the monitors it starts and kill them cleanly, or are the monitors supposed to run independently once kicked off?

IF YOU WANT TO KILL THE PROCESSES CLEANLY, your process when you are running the job is $$. You can grep the processes for any subprocesses you've kicked off and then kill them as you please.

IF THE MONITOR SHOULD RUN AFTER THE DRIVER ENDS, the command you want to use is nohup. And you probably want it to run in the background so that your processing can continue. Your command is "nohup <monitor -flags> &"

HTH,
Bambi.
-----Original Message-----
Sent: Monday, December 10, 2001 10:55 AM To: Multiple recipients of list ORACLE-L

I have a kshell script that I am trying to perform an oracle operation.

Everything works fine in the script excpet cleanup.

One section of the script spools off a monitor job that watches the script for any failures by use of flag files and file checking. This all works well UNTIL the main program ends before the monitor programs.

What happens is , that when the main program ends, the monitor closes down because it was spawned by the main program. Because of this, no all the flag files are getting deleted.

I need to know the proper trap to set and its syntax to catch an ending program so that I can get it to delete the flag files.

Anyone have any ideas ??

Thanks

Kevin

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Kevin Lange
INET: kgel_at_ppoone.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Bellows, Bambi
INET: BBellows_at_usg.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------