Yup!  We have a UNIX command that grabs the parent, child, grandchild... 
processes, then allow you to cleanly kill the chain of processes.  Nice little 
tool to ensure you get everything you need.


JRI

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Robert
Sent: Tuesday, June 26, 2012 3:10 PM
To: U2 Users List
Subject: Re: [U2] Runaway Jobs

Make sure that you kill all processes; the parent process and the child 
processes.

Also, sometimes you need to use the signal 9 with the kill command to make it 
work.

Robert Norman
ROBERT NORMAN & ASSOCIATES
Address: 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 Phone : 
951/541-1668 Email : i...@keyway.net
Website: http://users.keyway.net/~ice/
[Affordable UNIVERSE programming services for UniVerse Basic, PICK/BASIC, 
DATA/BASIC, UniBasic, R/BASIC, jBC]

Israel, John R. wrote:
> We are having occasional, random issues with runaway processes.
>
> We run lots of jobs through cron.  We pipe the output for each cron job to a 
> xxx.RESULTS file so that we can review them in case there are any issues.  
> All of our cron jobs do the following:
>   Set the needed environment variables
>   Cd to the desired account
>   Fire up a udt session
>   Execute the desired programs/processes that are fed to it
>   Print a standard "FINISHED" message
>   Exit UniData (which should then kill the Unix script)
>
> For some mysterious reason, random jobs will occasionally keep going.  Not 
> only does this eat up the CPU, but the xxx.RESULTS file gets HUGE!  Gigs in 
> size!  If we look at the contents of the RESULTS file, we see exactly what we 
> would have expected from the script/UniData.  It shows that it cleanly 
> executed the "off" command to terminate the udt session, but it then appears 
> to have carriage returns for millions of rows.  In fact, the udt process is 
> still active!  Even though we have typed the "off" command.  The RESULTS file 
> will just grow and grow at an alarmingly fast pace until once of us kills the 
> process.
>
> It is not consistent in any way that we have determined.  It is not the same 
> script getting stuck - it appears random.  A script that gets stuck in a 
> runaway status will work just fine the next time it runs.
>
> Has anyone experienced this before and if so, what was the solution?
>
> We are running:
>   HP-UX
>   Model mbhp7640
>   version of unix B.11.31 U
>   ia64 bit machine
>   Itantium box
>
>
>     Module Name         Version   Licensed
> UniData RDBMS............ 7.2     Yes
> Connection Pooling....... 7.2     No
> Device License........... 7.2     No
> NFA...................... 7.2     No
> RFS...................... 7.2     No
> EDA...................... 7.2     No
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
>   

_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to