Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Killing Processes

Reply
Thread Tools

Killing Processes

 
 
Oldbitcollector
Guest
Posts: n/a
 
      03-11-2006
Ok, I've done a couple days worth of searching on this one, and am
stuck. Here's the situation. I have a Linux/PERL script that runs from
inetd when someone telnets to the proper port. I have multiple copies
of this script running at any given time (multi user). When someone
simply drops their end of the connection, the program just stays
running hogging 99% (if it can take it) of the CPU.

I've tried to use alarm(300); while this works, it kills other valid
copies of the program when it drops the one I intended. Because they
all have the same name.

I've considered parsing a copy of "ps -x" to obtain which copies of the
script have been running for more than 5min, but this seems the sloppy
way to go. The nice part of this solution is that a running script
stays around 0:03 while it's under operation, then then starts adding
time after the user drops connection. They are obvious to spot.

Can anyone here provide some direction?

Thanks
Jeff

 
Reply With Quote
 
 
 
 
Peter J. Holzer
Guest
Posts: n/a
 
      03-11-2006
Oldbitcollector wrote:

> Ok, I've done a couple days worth of searching on this one, and am
> stuck. Here's the situation. I have a Linux/PERL script that runs from
> inetd when someone telnets to the proper port. I have multiple copies
> of this script running at any given time (multi user). When someone
> simply drops their end of the connection, the program just stays
> running hogging 99% (if it can take it) of the CPU.


You probably forgot to check for EOF on stdin.

> I've tried to use alarm(300); while this works, it kills other valid
> copies of the program when it drops the one I intended. Because they
> all have the same name.


Extremely unlikely. alarm kills only the process which called it, not all
processes with the same name. More likely each of your processes is killed
after 5 minutes by itself.

hp

--
_ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
|_|_) | Sysadmin WSR/LUGA |
| | | http://www.velocityreviews.com/forums/(E-Mail Removed) | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |
 
Reply With Quote
 
 
 
 
xhoster@gmail.com
Guest
Posts: n/a
 
      03-11-2006
"Oldbitcollector" <(E-Mail Removed)> wrote:
> Ok, I've done a couple days worth of searching on this one, and am
> stuck. Here's the situation. I have a Linux/PERL script that runs from
> inetd when someone telnets to the proper port. I have multiple copies
> of this script running at any given time (multi user). When someone
> simply drops their end of the connection, the program just stays
> running hogging 99% (if it can take it) of the CPU.


So why not fix the problem so it doesn't do that anymore? An ounce of
prevention is worth a pound of cure.

>
> I've tried to use alarm(300); while this works, it kills other valid
> copies of the program when it drops the one I intended. Because they
> all have the same name.


Eh, I don't think so. That isn't the way alarm works, at least not on
my system.

samename.pl:
fork and do {
alarm 5;
sleep;
};
sleep 10;
warn "still alive"
__END__

When I run samename.pl, after 5 seconds the parent exits on the alarm.
After five more the child claims to still be alive. (But you know how
children lie...)

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
robic0
Guest
Posts: n/a
 
      03-12-2006
On 11 Mar 2006 09:08:56 -0800, "Oldbitcollector" <(E-Mail Removed)> wrote:

>Ok, I've done a couple days worth of searching on this one, and am
>stuck. Here's the situation. I have a Linux/PERL script that runs from
>inetd when someone telnets to the proper port. I have multiple copies
>of this script running at any given time (multi user). When someone
>simply drops their end of the connection, the program just stays
>running hogging 99% (if it can take it) of the CPU.
>
>I've tried to use alarm(300); while this works, it kills other valid
>copies of the program when it drops the one I intended. Because they
>all have the same name.
>
>I've considered parsing a copy of "ps -x" to obtain which copies of the
>script have been running for more than 5min, but this seems the sloppy
>way to go. The nice part of this solution is that a running script
>stays around 0:03 while it's under operation, then then starts adding
>time after the user drops connection. They are obvious to spot.
>
>Can anyone here provide some direction?
>
>Thanks
>Jeff


Hey Jeffry,
Are u using Net::Telnet ?

"I have a Linux/PERL script that runs from
inetd when someone telnets to the proper port."

Inetd, is that a firewall debug program?
Dunno, not an expert, just asking?

Thanks
-robic0-
 
Reply With Quote
 
Oldbitcollector
Guest
Posts: n/a
 
      03-12-2006
>You probably forgot to check for EOF on stdin.

Could you expand on this a little bit? Yes, the software always stops
at
a keyboard entry routine, waiting for user input. This would be the
right
place to do something.

My main part of my input routine looks like this...

sub keyin {
$keyin="";
$idletime="";
$done='0';
while ($done eq '0') {
$key=getc(STDIN);
$idletime++;
#if ($idletime eq '100') {$show="$idletime";
&show;}

if (ord($key) eq 0x0D ) {
print $key;
$done='1';
}
elsif(ord($key) eq 0x0a ) {
print $key;
$done='1';
}
elsif(ord($key) eq 0x14 ) {
if(length($keyin) gt 0) {
#delete key
print $key;
$keyin=substr($keyin,0,length($keyin)-1);
}
}
else {
if ($texthide eq 'yes') {print "*";}
if ($texthide eq 'no') {print $key;}
#print ord($key);
$keyin.=$key;
}

}

}


Jeff

 
Reply With Quote
 
Oldbitcollector
Guest
Posts: n/a
 
      03-12-2006
>Hey Jeffry,
>Are u using Net::Telnet ?


No this is a system of my own making. Prob the strangest use for perl
this group has seen in a while. It's an old fashion C/G BBS system
written in perl.

Jeff

 
Reply With Quote
 
Oldbitcollector
Guest
Posts: n/a
 
      03-12-2006
I don't believe it... The answer was right in front of me the whole
time..

The addition of the following takes care of the problem.

if ($key eq "") { &terminateprogram }

Thanks allow me to think "out loud"

Jeff

 
Reply With Quote
 
Josef Möllers
Guest
Posts: n/a
 
      03-12-2006
robic0 wrote:

> On 11 Mar 2006 09:08:56 -0800, "Oldbitcollector" <(E-Mail Removed)>
> wrote:

[...}
>>Jeff

>
> Hey Jeffry,
> Are u using Net::Telnet ?
>
> "I have a Linux/PERL script that runs from
> inetd when someone telnets to the proper port."
>
> Inetd, is that a firewall debug program?
> Dunno, not an expert, just asking?


inetd (or xinetd) is the "inetrnet superdaemon" on Unix and Linux systems.
Rather than have a plethora of small server processes each starting up,
setting up their network ports and then eating up memory resources waiting
for connection requests that might never come, a single server process
([x]inetd) is configured to set up the internet ports for a set of services
and then this single process waits for a connect request on any of these
ports. If a connection request comes in, it spawns off and execs the real
server process, handing the connection on stdin/stdout/stderr (not 100%
sure about stderr) to the real server process.

This has several advantages:
1. only a single process is waiting (maybe for a connection request that
never comes) and consuming memory resources,
2. only a single process needs to perform host validation and access
restriction checking (hosts.allow/hosts.deny)
3. the actual server process gets the connection on stdin/stdout, allowing
simpler code in the server process (e.g. I've set up a logging server for a
project that took a hefty server process on Windows using only a very few
number of lines of Perl code on Linux and xinetd).

HTH,

Josef
--
josef punkt moellers bei gmx punkt de
 
Reply With Quote
 
Oldbitcollector
Guest
Posts: n/a
 
      03-12-2006
Ok, I thought I had it beat, but forgot that I'm also using
Term::Readkey in another section of the script. The original
getc<STDIN> doesn't work here, because I don't need it to wait for a
keypress this time, so Readkey was used instead. The same problem has
popped up, because this routine runs as a loop until the user types
/quit to exit.

Here's some of what it looks like....

loop:
$ckey="";
$ckey=Readkey(1);

## Various checking for delete key, etc here...

$ckey.=$ckey;
if ($ckeyin eq 'quit' ) {&terminate}

## Send information to the chatfile, etc.

goto loop;


The same problem crops up again, when someone drops their connection,
the loop continues to run. I can't use an if ($ckey eq "") because
that happens frequently in this use. What can I look for to find an
EOF?

Thanks,
Jeff

 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      03-13-2006
"Oldbitcollector" <(E-Mail Removed)> wrote:
> Ok, I thought I had it beat, but forgot that I'm also using
> Term::Readkey in another section of the script. The original
> getc<STDIN> doesn't work here, because I don't need it to wait for a
> keypress this time, so Readkey was used instead. The same problem has
> popped up, because this routine runs as a loop until the user types
> /quit to exit.
>
> Here's some of what it looks like....
>
> loop:
> $ckey="";
> $ckey=Readkey(1);


my copy of Term::ReadKey doesn't have a "Readkey" sub, but it does have
a "ReadKey".


>
> ## Various checking for delete key, etc here...
>
> $ckey.=$ckey;
> if ($ckeyin eq 'quit' ) {&terminate}
>
> ## Send information to the chatfile, etc.
>
> goto loop;
>
> The same problem crops up again, when someone drops their connection,
> the loop continues to run. I can't use an if ($ckey eq "") because
> that happens frequently in this use. What can I look for to find an
> EOF?


As far as I can tell, Term::ReadKey doesn't provide an easy way to
distinguish between the undef returned due to time-outs and the undef
returned due to EOF. And the eof function itself won't easily help you, as
it blocks indefinitely which apparently you don't want to happen. So my
first recommendation would be to forgo Term::ReadKey in favor of some
select (or IO::Select) based method.

Howver, if you want to keep using Term::ReadKey, you could take advantage
of the fact that (at least on my system) ReadKey returns immediately upon
eof but waits for the time-out period if not eof. So if it return many
times within one second (assuming you are using 1 second timeout) then you
are at eof.

use Term::ReadKey;
my $time=0;
my $count=0;
while (1) {
my $c=ReadKey(1);
if ($time==time()) {
last if ++$count==10;
} else {
$time=time; $count=0};
print defined $c?1:0, "\t$c\t$@\t$!"
}

There might also be a way to detect eof with GetControlChars, but I
couldn't figure it out.

Cheers,

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem killing nested Runtime.getRuntime().exec() processes bugbear Java 1 11-04-2005 12:11 PM
Listing/killing processes on IIS6.... Stu ASP .Net 2 08-02-2005 02:39 PM
Killing processes in CatOS Arnold Nipper Cisco 0 01-12-2005 05:33 PM
Killing processes hepp C++ 1 08-30-2004 07:57 PM
killing processes on win xp Andrei Python 1 02-13-2004 01:18 AM



Advertisments