Is there any way to make PHP wait until a function returns before continuing?
This is my code:
<?php
set_time_limit(0);
function waitforchange($nof) {
$lfilemod=filemtime($nof);
while(filemtime($nof) == $lfilemod) {
clearstatcache();
usleep(10000);
}
}
waitforchange('./blahblah.txt')
sleep(5);
echo 'done';
?>
It is supposed to wait until blahblah.txt changes, wait another five seconds after that, then print out "done", however, it prints out "done" after five seconds, regardless whether the file actually changed.
PHP is single-threaded, which means that it executes one instruction at a time before moving on. In other words, PHP naturally waits for a function to finish executing before it continues with the next statement.
I tried executing your code on my machine, and it properly waited and waited until I modified the file before completing the function and displaying the message.
I can't even see anything in your code that might be failing. Since the creation of $lfilemod is performed in the same way as the check in the while loop, the condition of that loop would return TRUE and execute even if there was a problem with the file (filemtime would return FALSE on both errors, so the condition would read (FALSE == FALSE, which is obviously TRUE).
Does your PHP script modify the file at all before running that loop? If it does, then the initial value returned by filemtime might be the modification time from when the script originally started. When you run clearstatcache in the loop, you'll pick up the new modification time caused by your changes earlier in the script.
My advice:
Try running clearstatcache before setting the value of $lfilemod so that you know the value is clean, and that you're comparing apples-to-apples with what is being checked in the loop.
Make sure the file really isn't being modified. Try placing a couple debugging lines at the start and end of your code which prints out the last modification time for the file, then comparing the two yourself to see if PHP is reporting seeing a change in modification time.
This should go without saying, but you should make sure that PHP is configured to display all errors during development, so you are immediately shown when and how things go wrong. Make sure that the display_errors setting is turned On in your php.ini file (or use ini_set() if you can't modify the file itself), and that your error_reporting() is set to E_ALL | E_STRICT for PHP <= 5.3, or E_ALL for PHP 5.4 (E_STRICT is part of E_ALL as of that version). A better way is to just set your error reporting to -1 which effectively turns on all error reporting regardless of PHP version.
Try running your code again with these modifications. If you see that the file really is being modified, then you know that your code works. If the file isn't being modified, you should at least have an error that you can look up, or ask us here.
Try assigning the function call to a variable. I think it doesn't wait for the return otherwise.
The code looks good; save for a missing semicolon (;) after the waitforchange line. I tested putting the (;) in there and the script behaved as intended. Perhaps that is the culprit? I am at loss though to explain how you got your code to execute at all with that error in there.
Related
So I have some legacy code thats going over the allotted memory, it would be a nightmare to try and figure out why and how to fix it. So I know you can do the dreaded: ini_set("memory_limit", "2048M"); but is there a way to then, after said code executes, reset the memory limit back to what it was?
You could try something like this (although I never tried it with memory limit)
//get the current limit
$memlimit = ini_get('memory_limit');
//set it to something else
ini_set("memory_limit", "2048M");
//... do some stuff
//set it back
ini_set("memory_limit", $memlimit);
I've used this for error reporting and a few other things (don't ask). So it might work :-/
I should also explain (just in case you don't know) setting anything with ini_set only affects the currently running PHP instance, so outside of that instance (request) everything will be what is in the php.ini file.
For reference (even thought it's pretty self explanatory)
http://php.net/manual/en/function.ini-get.php
ini_get — Gets the value of a configuration option
Yea so it's just a matter of getting the value, assigning it to a variable for storage, doing your thing, then setting it back to what it was.
Well this isn't true, I'm sure there's a reason, but I can't find it!!
I have a script that can take around 10 minutes to execute. It does a lot of communicating with an api on a service that we have that use. It pulls a bit of a fingerprint of everything every 24 hours. So what it's doing is pretty aside from the point. the probm I'm finding is the script stops executing somewhat randomly!!
I can't find any errors that would cause my script to stop executing, even with
//for debugging
error_reporting(E_ALL);
ini_set('display_errors', '1');
on for debugging, it's all clean. I've also used
set_time_limit(0);
so that it shouldn't ever time out.
With that said, I'm not sure how to get any more debug info to figure out what it's stopping. I can say that the script should NOT be hitting any memory limits or anything. I mean that should throw an error, and I've gone through and cleaned this script up as much as I can see to clean it up.
So my Question is: What are common causes for a cron ending when it shouldn't? How can I debug this more effectively?
You could try using a register_shutdown_function() to define a codeblock that will execute when the script shuts down. Then create a variable across the main code execution points in the cron with details of what is going on. In the shutdown function write this into a log and check your log to see what state the program was in when it stopped. Of course, this is based on the assumption that your code is not totally erroring out.
You could also redirect the standard echo statements and logs into a log file by using
/path/to/cron.php > /path/to/log.txt 2>&1
2>&1 indicates that the standard error (2>) is redirected to the same file descriptor that is pointed by standard output (&1).So, both standard output and error will be redirected to /path/to/log.txt
UPDATE:
Below is a function/flow that I usually use in my crons:
function addLog($msg)
{
if(empty($msg)) return;
$handle = fopen('log.txt', 'a');
$msg = $msg."\r\n";
fwrite($handle,$msg);
fclose($handle);
}
Then I use it like so:
addLog("Initializing...");
init();
addLog("Finished initializing...");
addLog("Calling blah-blah API...");
$result = callBlahBlah();
addLog("blah-blah API returned value". $result);
It is more tedious to have all these logs, but when cron messes up, it really helps!
For eg. when you look at your log.txt and if you see something like:
Initializing...
Finished initializing...
Calling blah-blah API...
And there is no entry which says blah-blah API returned value, then you know that the function call to blah-blah messed up.
What are common causes for a cron ending when it shouldn't?
The most common in my experience is that the cron user has different permissions or different environment variables than the way that you're executing it from the command line.
Make your cronned program dump its environment to a temporary file and see if it's what you expect.
I've a PHP script that outputs a file to the user (as a download) which is also used to record what the user is downloading.
Basic structure is this:
set_time_limit(0);
ignore_user_abort(true);
register_shutdown_function('shutdown_fn'); //as a fail safe (i think)
//some other code here
//do some mysql queries
while(!feof($fh) && !connection_aborted()) {
echo fread(....);
ob_flush;
ob_end_flush;
sleep(1);
}
fclose($fh);
//do some more mysql queries here and set a boolean to track if it was done successfully
function shutdown_fn () {
//check boolean to see if queries failed, if so, do them here
}
The above code seems to work 99% of the time just fine. However, there are some instances when the second set of queries don't execute at all (the other 1%). I have no idea why. The files being sent to the user range from very small to very large (and in both cases they work just fine so i cant see how a large file (or small file) would be breaking the code).
Any thoughts? I hope i have explained myself well enough
I need to see some more code like the opening/reading of the file to further help you, but if you really want to be sure and not depend on the one shutdown_fn() function then why not call it yourself as well on the end of the script? Reset the boolean in the shutdown_fn() so whenever the actual shutdown is triggered than your sql queries are not ran twice.
I am well aware about error_reporting(0); & ini_set('display_errors', "Off"); to make error messages go away.
What would be an appropriate way to do this - for a specific file or part of code only?
Surpressing errors with #'s seems like a bad idea since it apparently slows the code down...
The reason? We have a number of memcached servers in a development LAN that is really unreliable due to the network settings, thereby we are recieving errors multiple times every hour and there's nothing we can do about it except stop using memcache or turning off errors for the whole application, which would be giving us a headache - in the middle of the development stage :)
<?php
// normal code
// error_reporting returns the old error code
$old_error_reporting = error_reporting(0);
// your errorful code
// reset error_reporting to its old value
error_reporting($old_error_reporting);
// normal code
Although it would be a good idea to fix what is actually causing the errors.
You've kind of answered your own question. To do it for a specific file, error_reporting(0); will turn off errors. You can also call it multiple times in a script, I think.
You can also use php exceptions to 'catch' errors over a block of code. For example:
try {
// code to ignore errors for here
} catch {
// you can output a custom error here, but putting nothing here will effectively mean errors are ignored for the try block
}
The script will continue running past the try block, even if there is an error within it. See the PHP Manual Entry for more information.
You can change the error reporting level during runtime:
<?
error_reporting(E_ALL);
... some code ....
error_reporting(0);
... some more code ....
error_reporting(E_ALL);
I know of no other way but I can't think of a case where this wouldn't be sufficient. Can you?
That's really a long time ago but someone like me would maybe use my answer.
When i need to do this kind of stuff, i just put # before the variable in order to NOT display the errors coming from this variable.
example:
switch(#$var!="e") {
....
}
Say you have a large PHP project and suddenly, when attempting to run it, you just end up with a blank page. The script terminates and you want to find exactly where that is with as little effort as possible.
Is there a tool/program/command/IDE that can, on PHP script termination, tell you the location of a script exit?
Note: I can't mark my own post as "accepted answer" so look at the bottom to see my solution. If you come up with a better solution I will mark your post as the answer.
I use the following code and need no special debugging environment. Note that this might take really long; you can set the ticks count higher - that makes it faster, but blurry.
function shutdown_find_exit()
{
var_dump($GLOBALS['dbg_stack']);
}
register_shutdown_function('shutdown_find_exit');
function write_dbg_stack()
{
$GLOBALS['dbg_stack'] = debug_backtrace();
}
register_tick_function('write_dbg_stack');
declare(ticks=1);
With some inspiration from the nonworking but still right-direction answer from RoBorg, I used the following code in the beginning:
function shutdown() {
global $dbg_stack_a;
print_r($dbg_stack_a);
}
register_shutdown_function('shutdown');
And then I made a global conditional breakpoint (global = breakpoint is evaluated on each row), exploiting the fact that it can run code trough eval(), with the following "condition":
eval('
global $dbg_stack_a, $dbg_stack_b, $dbg_stack_c;
$dbg_stack_a = $dbg_stack_b;
$dbg_stack_b = $dbg_stack_c;
$dbg_stack_c = debug_backtrace();
return false;
')
Probably not fast but does the trick! Using this I was able to determine the exact file and line location that raised die(). (This example works in NuSphere.)
grep -n die filename
Don't forget to grep for "exit" too.
Add this to the top of the file:
function shutdown()
{
print_r(debug_backtrace());
}
register_shutdown_function('shutdown');
See register_ shutdown_function()
You can use an interactive debugger to step through the code until you reach the exit point. Other than that, I think you're down to grep'ing the code for exit|die.
xdebug has a nice trace feature that'll allow you to see all the entire trace of your php app execution and it should give you give clue as to where your exit is.
but for the quick and dirty solution a grep/find as mentioned above will do rightly.
Also check the error___logs for "memory_limit" errors in the Apache error_log.
Memory Limit >= 10M Warning: (Set this to 10M or larger in your php.ini file)
In my experience, scripts suddenly end without warning or notice when this happens.
Make sure that errors are displayed in your development environment (not production).