I have an IIS server which is serving PHP via fastcgi.
When the error log file is written to by a user other than one in IIS_IUSRS group (The group the IIS User is running under) the file becomes un-writable by IIS and the PHP calls to error_log() causes a 500 error. (At least that's my guess seeing as if I delete the log file, the error dissapears and the log file is re-created).
Is there anyway I can stop the 500 error from happening?
EDIT: To be clear I know I can stop this by stopping logging, logging to event log or different location etc, but that's not what I mean. I mean I just want to prevent the 500 error, I don't care enough that my system can't log that it should break the site when it tries to. That's exactly the worst behaviour it could have. I just want the 500 error to not happen and the site to continue working.
Since your scheduled task is actually changing the permissions on the error log file, the only viable options I can see are:
1) Make the scheduled task not write to the error_log. Add the following to the top of the cron job:
error_reporting(E_NONE);
2) Make the scheduled task write to the system log (event viewer in windows) by issuing the following command at the start of your scheduled task (PHP file):
ini_set('error_log', 'syslog');
3) If all of the above do not suit you, you can try scheduling the task as the IIS User/Group. This would insure that the permissions are met and error 500 is no longer caused.
There is no magic fix to this, you can either change the scheduled task so it has the same UID/GID as the PHP process, or you can stop logging in the scheduled_task.
Edit the php.ini, and find this line and edit:
error_log = /your/website/path/to/log
And sure to change the display_errors to off:
display_errors = off
Remember to put chmod 777 to the file :). If u wanna to see the file in the browser, can put something like this in the .htaccess file:
<Files /your/site/path/to/log/file.log>
allow from 10.0.1.1/16
deny from all
</Files>
PS: Sry, i dnt see the notation are a ISS server... hum, maybe can view more information about the error in the error_log of the ISS (i dont know where is)
I experienced this. Your error_log might be too big for a file. For example, when your error_log reaches 16mb the server will throw an error 500. You may delete your error_log and try if it still throws that error. You may wanna check the error_logs permissions and ownership too.
You want to avoid the error_log function from throwing a 500 Internal Server Error!
Well, if that may be the case, have you tried prepending your call to error_log with an '#'. That could possibly suppress the error. Please try and revert! :)
You could try using error_log() to write your application log in an alternative path:
error_log("Some fancy error to log", 3, "c:\tmp\your-custom-errors.log");
Or you could configure php to log to windows event log (in your php.ini):
error_log = syslog
Related
I am having an issue when I have a php application that is returning an internal server error (500) however nothing is showing up in the error log.
Now I know there are error with what I am trying to run, I know I have missing some files and what not but something should show in the apache error log (otherwise how are I supposed to know exactly what I am missing).
I created a test script is errors it in under the same vhost configuration and those error show up fine so everything seems configured right as far as php/apache. Are there certain php errors that does show up in the error log (php is configure to display any type of notice, warning, , error, fatal error, etc...)?
This is running on ubunut 10.04 with the standard apache and php from the ubuntu repo with apt-get.
Scan your source files to find #.
From php documentation site
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
Copy and paste the following into a new .htaccess file and place it on your website's root folder :
php_flag display_errors on
php_flag display_startup_errors on
Errors will be shown directly in your page.
That's the best way to debug quickly but don't use it for long time because it could be a security breach.
If you still have 500 error and no logs you can try to execute from command line:
php -f file.php
it will not work exactly like in a browser (from server) but if there is syntax error in your code, you will see error message in console.
Maybe something turns off error output. (I understand that you are trying to say that other scripts properly output their errors to the errorlog?)
You could start debugging the script by determining where it exits the script (start by adding a echo 1; exit; to the first line of the script and checking whether the browser outputs 1 and then move that line down).
In the past, I had no error logs in two cases:
The user under which Apache was running had no permissions to modify php_error_log file.
Error 500 occurred because of bad configuration of .htaccess, for example wrong rewrite module settings. In this situation errors are logged to Apache error_log file.
For Symfony projects, be sure to check files in the project'es app/logs
More details available on this post :
How to debug 500 Error in Symfony 2
Btw, other frameworks or CMS share this kind of behaviour.
Here is another reason why errors might not be visible:
I had the same issue. In my case, I had copied the source from a production environment. Hence the ENVIRONMENT variable defined in index.php was set to 'production'. This caused error_reporting to be set to 0 (no logging). Just set it to 'development' and you should start seeing error messages in apache log.
Turned out the 500 was due to a semi colon missing in database config :-)
Another case which happened to me, is I did a CURL to some of my pages, and got internal server error and nothing was in the apache logs, even when I enabled all error reporting.
My problem was that in the CURL I set
curl_setopt($CR, CURLOPT_FAILONERROR, true);
Which then didn't show me my error, though there was one, this happened because the error was on a framework level and not a PHP one, so it didn't appear in the logs.
You need to enable the PHP error log.
This is due to some random glitch in the web server when you have a php error, it throws a 500 internal error (i have the same issue).
If you look in the PHP error log, you should find your solution.
see here in the doc of how to enable it in the php.ini
Be sure your file permissions are correct. If apache doesn't have permission to read the file then it can't write to the log.
What happened for me when this was an issue, was that the site had used too much memory, so I'm guessing that it couldn't write to an error log or displayed the error. For clarity, it was a Wordpress site that did this. Upping the memory limit on the server showed the site again.
SOLVED
I struggled with this and later on, I realized that I was working on PHP 5.6, so I upgraded to PHP 7.0, then I released there were comments placed by git for conflicting codes. I found something like this in my code <<<<<<<< But solved it.
Im running a long php script which handles large amounts of data.
The problem is that the script suddenly stops and no exception is thrown or could be found on the error_log.
I have set the display_errors and the error_logging to 1 in the .ini config file.
Few more details:
1) The scripts executes the 'file_get_contents' function for many times.
2) The scripts contains recursion when the file_get_contents fails.
Any help would be appriciated.
It might have hit the max execution time.
set_time_limit(0); // to increase the timelimit to infinity
Error loging configs are different depending on your hosting environment. I'd first verify that you're editing the right php.ini file. Take a look at your phpinfo output and make sure that those params are indeed set and check the path/file for where errors are being logged to. Sometimes it goes to the apache error log, other times it can be sent to a dedicated php log. Are you able to get any error output if you purposefully create a syntax error? You might also consider looking in your syslog to see if there's anything there.
I am having an issue when I have a php application that is returning an internal server error (500) however nothing is showing up in the error log.
Now I know there are error with what I am trying to run, I know I have missing some files and what not but something should show in the apache error log (otherwise how are I supposed to know exactly what I am missing).
I created a test script is errors it in under the same vhost configuration and those error show up fine so everything seems configured right as far as php/apache. Are there certain php errors that does show up in the error log (php is configure to display any type of notice, warning, , error, fatal error, etc...)?
This is running on ubunut 10.04 with the standard apache and php from the ubuntu repo with apt-get.
Scan your source files to find #.
From php documentation site
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
Copy and paste the following into a new .htaccess file and place it on your website's root folder :
php_flag display_errors on
php_flag display_startup_errors on
Errors will be shown directly in your page.
That's the best way to debug quickly but don't use it for long time because it could be a security breach.
If you still have 500 error and no logs you can try to execute from command line:
php -f file.php
it will not work exactly like in a browser (from server) but if there is syntax error in your code, you will see error message in console.
Maybe something turns off error output. (I understand that you are trying to say that other scripts properly output their errors to the errorlog?)
You could start debugging the script by determining where it exits the script (start by adding a echo 1; exit; to the first line of the script and checking whether the browser outputs 1 and then move that line down).
In the past, I had no error logs in two cases:
The user under which Apache was running had no permissions to modify php_error_log file.
Error 500 occurred because of bad configuration of .htaccess, for example wrong rewrite module settings. In this situation errors are logged to Apache error_log file.
For Symfony projects, be sure to check files in the project'es app/logs
More details available on this post :
How to debug 500 Error in Symfony 2
Btw, other frameworks or CMS share this kind of behaviour.
Here is another reason why errors might not be visible:
I had the same issue. In my case, I had copied the source from a production environment. Hence the ENVIRONMENT variable defined in index.php was set to 'production'. This caused error_reporting to be set to 0 (no logging). Just set it to 'development' and you should start seeing error messages in apache log.
Turned out the 500 was due to a semi colon missing in database config :-)
Another case which happened to me, is I did a CURL to some of my pages, and got internal server error and nothing was in the apache logs, even when I enabled all error reporting.
My problem was that in the CURL I set
curl_setopt($CR, CURLOPT_FAILONERROR, true);
Which then didn't show me my error, though there was one, this happened because the error was on a framework level and not a PHP one, so it didn't appear in the logs.
You need to enable the PHP error log.
This is due to some random glitch in the web server when you have a php error, it throws a 500 internal error (i have the same issue).
If you look in the PHP error log, you should find your solution.
see here in the doc of how to enable it in the php.ini
Be sure your file permissions are correct. If apache doesn't have permission to read the file then it can't write to the log.
What happened for me when this was an issue, was that the site had used too much memory, so I'm guessing that it couldn't write to an error log or displayed the error. For clarity, it was a Wordpress site that did this. Upping the memory limit on the server showed the site again.
SOLVED
I struggled with this and later on, I realized that I was working on PHP 5.6, so I upgraded to PHP 7.0, then I released there were comments placed by git for conflicting codes. I found something like this in my code <<<<<<<< But solved it.
I'm using ssh2_scp_send to send one file from server1 to server2.
It works almost 80% of the times, but sometimes fails and I can't find any log message and i don't know why!
the command only return one bool value saying if it was sucessfull.
ssh2_scp_send
Where can I find some log message or any of you had one similar problem?
Thanks,
Pedro
#pedro
The path to the PHP error log is defined with "error_log" in PHP.ini. In your PHP script you should display all errors during development.
error_reporting(E_ALL);
You can also choose to show errors in the PHP output.
ini_set('display_errors', 1);
There is an alternative shown on:
http://php.oregonstate.edu/manual/en/function.ssh2-scp-send.php#82927
That may give you more flexible error handling.
PHP SSH2 is a probably a wrapper around the "libssh2", so if you are looking for logs then check your syslog config file, if ssh logging is not enabled in there then ssh logs the activity in apache log files. Logs are generally stored in /var/log
One good debugging technique would be to enable logging in php.ini
log_errors = On
error_log = /path/to/logfile.log
ssh2_scp_send fails for me if the file size is more then 2 GiB, it uploads 2 GiB and then stops.
I was wondering if anybody knew of a method to configure apache to fall back to returning a static HTML page, should it (Apache) be able to determine that PHP has died? This would provide the developer with a elegant solution to displaying an error page and not (worst case scenario) the source code of the PHP page that should have been executed.
Thanks.
The PHP source code is only displayed when apache is not configured correctly to handle php files. That is, when a proper handler has not been defined.
On errors, what is shown can be configured on php.ini, mainly the display_errors variable. That should be set to off and log_errors to on on a production environment.
If php actually dies, apache will return the appropriate HTTP status code (usually 500) with the page defined by the ErrorDocument directive. If it didn't die, but got stuck in a loop, there is not much you can do as far as I know.
You can specify a different page for different error codes.
I would assume that this typically results in a 500 error, and you can configure apaches 500 handler to show a static page:
ErrorDocument 500 /500error.html
You can also read about error handlers on apaches documentation site
The real problem is that PHP fatal errors don't cause Apache to return a 500 code. Errors except for E_FATAL and E_PARSE can be handled however you like using set_error_handler().
There are 2 ways to use PHP and Apache.
1. Install PHP as an Apache module: this way the PHP execution is a thread inside the apache process. So if PHP execution fails, then Apache process fails too. there is no fallback strategy.
2. Install PHP as a CGI script handler: this way Apache will start a new PHP process for each request. If the PHP execution fails, then Apache will know that, and there might be a way to handle the error.
regardless of the way you install PHP, when PHP execution fails you can handle errors in the php.ini file.