Php script to KILL cron job

Depending on what the loop is doing (accessing a database, including other scripts, etc), you could try some temporary renaming to cause an error.

If you have control of system options, you could set the maximum script run time to a small number.

yodercm,

The script is executing a do-while loop where a preg_match doesn't return correct results. Yes, I now have a correct stopping if statement in the loop.

I'd like to learn how to Kill a cron job using the info I provided.

Thanks for your reply,
David

I don't see how one php script could stop another that is already running.

I thought it must be possible to give the cron daemon instructions to execute on another process (PID) especially if it is from the same user.

I am looking into your suggestion about setting a script runtime limit. That may be the answer. It's dependent on safe mode, so I'll check.

A PHP Cron job should obey the time_limit() functions.  You can ask the server administrators to kill it for you, but it is unlikely that you can kill it yourself.  If you add a little code to look for an incremented counter or something like that, you can stop after a certain number of iterations.

WizRd-Linux,

Thanks for your reply. That looks promising, yet dangerous. When I spoke to the hosting company (they were very vague), they asked about the process id. Do you think it's possible to run a php script with the shell_exec ( ) command, and what wouldn't there have to be a reference to the PID and other details in that sudo kill ?

I only want to kill one 'runaway' script that's been executed via cron daemon from my domain.

?? Still looking for the answer.

If you have contact with the hosting company, just give them whatever you can and tell them to kill it.  They don't want a permanently running script any more than you do.  

If you don't know the process id, ask them how you find it.

Then put time limits into any script that might be a problem.  Frankly, I can't imagine any hosting company that doesn't have built-in time limits on all jobs.

If it is a run away script you can get the pid of the process running that particular script using" lynx --dump http://localhost/server-status"

In the apache configuration you need to make sure that the "ExtendedStatus On" directive exists or you won't get the correct output.

You can then cut out the line and use the second field which is the PID of the apache process running the script.  An example output looks like:

0-3 19204 0/135/236 _ 21.17 45 0 0.0 0.48 0.65 219.90.162.252
   www.domain.com GET /screen.php HTTP/1.1

The 19204 number on the first line is the PID of the apache process.

the best solution is to replace your croned file that does nothing...

<?php

?>

replace croned file with a blank php and let it run as normal without any effect

<?php
 
?>

Select allOpen in new window

Thanks to WizRd-Linux & Uberpappa for your suggestions.

The php shell_exec ( ) did work for me on a public server. This is a two step process made easy by the runaway script 'writing' output to a fopen ( ) file when the html output will never happen. So, with the first line of the output file being the output in my question, ( I only need the PID ), and using a second file /end_proc.php?pid=12345, I can quickly and easily kill a runaway program with another program.

The keys to this is being able to :
Write the php function 'getmypid ( )' to a file (for PID viewing) and,
Use shell_exec ( ) to stop it.

Not being familiar with bash, I did not test that method.

<?php
 
if ( @isset ( $_GET['pid'] ) )
{
	$pid = $_GET['pid'];
}
 
$output = shell_exec ( "kill -9 $pid" );
 
echo "<pre>$output</pre>";
 
?>

Select allOpen in new window

WizRd-Linux, thanks for your suggestion to use shell_exec ( ). Uberpappa, your suggestion really made the solution possible.

I forgot to include two thoughts:

I think safe_mode IS enabled on this server, but it seemed to kill the runaway anyway. Maybe because they are both from the SAME user.

Also, the $output echoed to the screen returned absolutely nothing. I had no idea that the script had been killed until looking at the file ( $fp ) being written to.

Well, you're welcome for my help as well, even if you were rude enough not to acknowledge it.