Re: Killing Processes Code Review

I did not understand what you are trying to do exactly.

Are you trying to kill the process if it's been running for more than 1 hour ? or you are killing the process if it doesn't match a given date/time you saved in a local file?

Does your code actually do the job? The process killing part might kill 1 process only ... is that what you really want? Here's your code which might be matched 1 time only

if ($counter == scalar(@rundates)) { 
            print "$procids[$procloop] is outside expected time range.
+\n" ;
            my $cmd = "ssh $nodenum kill -9 $procids[$procloop]";
            #print is to see if anything is killed, and make sure comm
+and syntax is correct
            print "$cmd\n";
            system ($cmd);
        }
[download]

And you can avoid some of your problems like # if the 'ps' output changes order, than may cancel the wrong process by not running separate ssh commands , but using 1 command and parse the output yourself.

Comment on Re: Killing Processes Code Review Download Code

Replies are listed 'Best First'.
Re^2: Killing Processes Code Review by Anonymous Monk on Sep 13, 2010 at 15:42 UTC
Sorry for not responding until now - should have thought about putting this up on a Friday. But to answer: Are you trying to kill the process if it's been running for more than 1 hour ? or you are killing the process if it doesn't match a given date/time you saved in a local file? A little of both. I get times from the first grep command, then compare them to the second and third grep results. If they differ by more than an hour, then it should kill the process. I put the time difference in because the ps command was giving times from the future, so I thought some margin would be good. Does your code actually do the job? The process killing part might kill 1 process only ... is that what you really want? I only want it to kill processes outside of the time buffer - so even if doesn't actually kill anything, that's fine. The goal is just to get those accidentally left behind, not the ones actually in use. And it does seem to work, at least based on the tests I could come up with. Not knowing why processes continue makes testing hard. parse the output yourself The idea with this is to be automated, and possibly even to run automatically at given points. It's not really that much work to do the whole code's function manually, but it needs to be done regularly.	[reply]

Replies are listed 'Best First'.

Re^2: Killing Processes Code Review
by Anonymous Monk on Sep 13, 2010 at 15:42 UTC

Sorry for not responding until now - should have thought about putting this up on a Friday. But to answer:

Are you trying to kill the process if it's been running for more than 1 hour ? or you are killing the process if it doesn't match a given date/time you saved in a local file?

A little of both. I get times from the first grep command, then compare them to the second and third grep results. If they differ by more than an hour, then it should kill the process. I put the time difference in because the ps command was giving times from the future, so I thought some margin would be good.

Does your code actually do the job? The process killing part might kill 1 process only ... is that what you really want?

I only want it to kill processes outside of the time buffer - so even if doesn't actually kill anything, that's fine. The goal is just to get those accidentally left behind, not the ones actually in use. And it does seem to work, at least based on the tests I could come up with. Not knowing why processes continue makes testing hard.

parse the output yourself

The idea with this is to be automated, and possibly even to run automatically at given points. It's not really that much work to do the whole code's function manually, but it needs to be done regularly.

[reply]