Runaway Processes
John Hatcher
system. The problem we are having, is instead of disconnecting properly for
our servers, our people are just closing the windows. Hence we have a lor
of runaway processes.
What I would like to do is find out how to kill these automatically after a
certain time has passed.
--
John Hatcher
Systems Engineer
Laser Courier
Tom Parsons
| We are using a windows based telnet program to access our order entry
| system. The problem we are having, is instead of disconnecting properly for
| our servers, our people are just closing the windows. Hence we have a lor
| of runaway processes.
|
| What I would like to do is find out how to kill these automatically after a
| certain time has passed.
Teach the users to log out properly
Get an emulator that does a better job of closing sessions
Get the application fixed so it won't misbehave and start runaway processes.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
David Mabo
(of zombies) disappeared for us a few years ago.
John Hatcher wrote:
>
> We are using a windows based telnet program to access our order entry
> system. The problem we are having, is instead of disconnecting properly for
> our servers, our people are just closing the windows. Hence we have a lor
> of runaway processes.
>
> What I would like to do is find out how to kill these automatically after a
> certain time has passed.
>
> --
> John Hatcher
> Systems Engineer
> Laser Courier
--
David H. Mabo, CPCM
Adaptix Corp. - Cincinnati, Ohio
John DuBois
Tom Parsons <c...@tegan.com> wrote:
>John Hatcher enscribed:
>| We are using a windows based telnet program to access our order entry
>| system. The problem we are having, is instead of disconnecting properly for
>| our servers, our people are just closing the windows. Hence we have a lor
>| of runaway processes.
>|
>| What I would like to do is find out how to kill these automatically after a
>| certain time has passed.
>
>Get an emulator that does a better job of closing sessions
>Get the application fixed so it won't misbehave and start runaway processes.
These are definitely the best options.
If all else fails, you can try using CPU time limits to prevent having the
runaway processes run and suck up CPU time forever (this assumes that by
"runaway processes" you mean processes that are actually using CPU time).
This would involve using the process accounting system to determine the maximum
amount of CPU time ever legitimately used by the application (which shouldn't
be too high if the users log out at the end of each day), and then using ksh's
"ulimit -t" facility to set the maximum amount of CPU time the application can
use before being killed to something higher than that.
There may be other things you can do depending on what release of the OS you're
using.
John
--
John DuBois spc...@armory.com. KC6QKZ/AE http://www.armory.com./~spcecdt/
Tom Parsons
| What version of SCO - between OS upgrade and better apps, these problems
| (of zombies) disappeared for us a few years ago.
|
| John Hatcher wrote:
| >
| > We are using a windows based telnet program to access our order entry
| > system. The problem we are having, is instead of disconnecting properly for
| > our servers, our people are just closing the windows. Hence we have a lor
| > of runaway processes.
| >
| > What I would like to do is find out how to kill these automatically after a
| > certain time has passed.
Impossible. By definition, zombies cannot consume resources.
There is one commercial package (language?) that has exhibited this problem
for many years, (long before OpenServer) and while it existed with serial
terminals, it wasn't as prevalent a problem.
Tony Lawrence
> Impossible. By definition, zombies cannot consume resources.
A process slot is a resource :-)
But more seriously, consider this: a zombie whose parent has gne
away will be inherited by init and will subsequently be taken
care of automagically. If the parent has NOT itself died, then
the zombie hangs about, and while it is not consuming resources
(other than a process slot), its uncaring parent probably is.
Therefore zombies are sometimes a sign of a true problem although
they themselves are only a symptom.
--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com
Tom Parsons
Interesting method.
I use your proctree program (ftp.armory.com:/pub/scripts/proctree) as the
basis for a shell script that attempts to kill the processes on each tty
in reverse order. This usually gets children before they get disconnected
from their parents and controlling tty.
Kevin Smith, ShadeTree Software, Inc.
>We are using a windows based telnet program to access our order entry
>system. The problem we are having, is instead of disconnecting properly for
>our servers, our people are just closing the windows. Hence we have a lor
>of runaway processes.
>
>What I would like to do is find out how to kill these automatically after a
>certain time has passed.
This is a common problem with Throughbred Business Basic and maybe
other applications. I use the following wrapper when starting
basic, to handle just your problem.
Note: the program is "tuned" to Throughbred in that basic normall
handles interrupt and quit signals so the wrapper explicitly
ignores them. You may want to change that behavior.
It does two things. First it traps sighup and sigterm then starts
the child process. If it receives a sighup or sigterm it sends
first a SIGQUIT to the child process (this is Throughbred dependent
behavior that you probably would want to change. Probably a SIGTERM
is better), waits five seconds and sends a SIGKILL (kill -9) just
to be sure. Secondly, it wakes up every 30 seconds and tests if
we are attached to a tty by attempting to open /dev/tty. If that
fails, it kills the child as above.
This handles two failure modes of Throughbred to having a session
closed. One, it would trap/ignore the SIGHUP that it received when
the window was closed. Secondly it would spin internally if it
started getting EOF's from the terminal input as it didn't handle
this unexpected behavior.
============= bk.c ==============
/*|
|*| @(#)bk.c--execute basic and kill it if necessary
|*|
|*| start basic, ignore all signals except SIGHUP, SIGTERM.
|*| Wait for basic. If we get a signal while waiting, SIGKILL
|*| basic and exit non-zero.
|*|
|*| ShadeTree Software, Kevin Smith
|*| No rights reserved, no responsibility acceptd!
|*/
char *what[]={
"@(#)bk--start basic with SIGHUP trap",
"@(#)usage: bk <command> [arguments]",
"@(#)STS/KBS 04/01/91",
"@(#)bk.c 1.2"
};
#include <stdio.h>
#include <errno.h>
#include <sys/signal.h>
#include <sys/wait.h>
#define POLLTIME 30 /* Polling interval */
int bpid; /* basic process id */
void trap(int);
void killb();
extern int errno;
main(ac,av)
int ac;
char *av[];
{
int wpid; /* wait process id */
int cstat; /* child wait status */
if(ac<2) usage();
if((bpid=fork())==0) {
/* child--execute command */
return(execvp(av[1],av+1));
} else {
if(bpid<=0) {
fprintf(stderr,"fork failed\n");
return(2);
}
/*|
|*| trap hangups and terminates for special processing
|*/
signal(SIGHUP,trap);
signal(SIGTERM,trap);
/*|
|*| ignore interrupts and quits. basic will handle, we don't care
|*| all other signals are left to their own devices
|*/
signal(SIGINT,SIG_IGN);
signal(SIGQUIT,SIG_IGN);
/*
* Set the alarm trap and alarm for polling.
*/
signal(SIGALRM,trap);
alarm(POLLTIME);
/*|
|*| wait for process to finish and return it's exit code
|*/
do {
wpid=wait(&cstat);
if(wpid==-1) {
if(errno == EINTR) {
/*
* If we were interrupted (alarm)
* see if we are still attached to a tty.
* If not, kill the child process and go back to
* waiting. The wait() should catch the dead
* child.
*/
if(notty()) {
killb();
}
} else {
/*
* If we got some other (not an interrupt) than
* something must be wrong.
*/
break;
}
}
} while(wpid != bpid);
return(cstat);
}
/* NOTREACHED */
}
void
killb()
{
kill(bpid,SIGQUIT);
sleep(5);
kill(bpid,SIGKILL);
}
void
trap(signum)
int signum;
{
signal(signum,trap); /* reset trap */
switch(signum) {
case SIGHUP:
case SIGTERM:
killb();
break;
case SIGINT:
case SIGQUIT:
/*
* We should be ignoring these.
*/
exit(1);
case SIGALRM:
/*
* If we caught an alarm, reset the timer for
* continious polling.
*/
alarm(POLLTIME);
break;
default:
kill(bpid,signum);
break;
}
}
/*
* Test for control tty.
* Returns 0 if tty, 1 if not.
*/
notty()
{
int fd;
if((fd=open("/dev/tty",0))>=0) {
/*
* Open successfull--tty is ok.
*/
close(fd);
return(0);
}
/*
* Open failed--No tty.
*/
return(1);
}
usage()
{
fprintf(stderr,"%s\n",what[1]+4);
exit(1);
}
--
Do two rights make | Kevin Smith, ShadeTree Software, Philadelphia, PA, USA
a libertarian | 001-215-487-3811 shady.com,kevin bbs.cpcn.com,sysop
| dvtug.org,kevins--Delaware Valley Transit Users Group