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