Is there a PHP function or some other way of obtaining the PHP error log as a string?
I need this because I cannot access the error log of a site I am running on someone else's server. - He offered to email me the error log, but that isn't exactly convenient.
Is there some way I could output the error log to a PHP page?
I realize that viewing the entire server's error log is not really going to happen for me. However, I know you can do something like this to email a manual error_log call to yourself:
error_log('A really bad error', 3, 'me#myemail.com');
Is it possible to configure a page to email errors to you instead of displaying them?
On a badly secured server, yes. But on most servers there are two users: apache and [ you ]. You don't have access to the server logs, since they are owned by the apache user (or whichever server you're using).
However, you could probably try it:
echo file_get_contents('/var/log/httpd/error_log');
Note: that's the default location on a RedHat-based apache server. It may be different
Update To reflect the updated question
No, you cannot view the error log with error_log - it is a one-way process that gets handled by the webserver. It only writes the log, but you cannot read it.
You can probably display the errors with this:
ini_set('display_errors', 'On');
error_reporting(E_ALL);
You could even use set_error_handler to handle all warnings and notices (for example, to mail them). But that's pretty much all you can do.
Related
In localhost, we can easily find the errors like missing semicolon in line number xxx, undefined variable in line number xxx,class already declared etc. But, when I upload all my files in shared hosting and try to see results in the web browser, I get to see same error page everytime and it's really really hard to detect what exactly caused the error. The project which i uploaded to the live server was written in laravel. I have tried 'Display errors On' in php.ini, error_reporting(E_ALL). I have even checked the error_log in the root directory but, those logs are usually from few days ago. error image description here
Any possible solutions ? Or should I switch to server where proc_open is enabled?
Check this:
https://laravel.com/docs/7.x/errors
Laravel handles errors and can write them in a log file.
You can customize it if you want, but I don't think it's necessary to do so.
If you dont use any frameworks or ones that don't support such a feature for that matter you could always use the native PHP function set_error_handler and catch errors and write them in a log file.
Note: BEWARE of the excessive log file size. If your project has a lot of visitors or has lots of notices and warnings, this log files can get excessively massive, unreadable, and consuming your space. Don't turn it off, it's always good to know where are the errors, but check and debug them often and delete them when not needed.
I am checking if the cookie exists or not. Code run perfect on localhost but not working on server.
if(!isset($_COOKIE['checkuser']))
{
// Create a cookie
}
else
{
// do other other action
}
page is not being load on if accessing from webserver. but on localhost its work fine. is there is some setting that I need to do for this ?
If your error is "the page is not loading" then it is almost certainly not related to the code you posted. You mention in a comment that you're doing some database calls in code you didn't post - that's far more likely to cause trouble than an isset() call.
What error are you seeing? If you are seeing just a blank page, that's likely a syntax error which is being logged to the server's error log rather than to the screen, for security purposes. Check your server's error logs for an associated message.
It's likely your server is running either a different version of PHP or a different security level (PHP safe mode, for instance) which is causing it to fail on the server but not on your machine. Alternatively, it may be failing to connect to the server's database.
Please update your question with more information (more code and/or the exact error message would be a good start) if this isn't enough information to solve your problem.
Is it possible to configure php.ini to store errors in MySQL database rather than plain error-log?
The only option that I see is using php.ini to append file containing custom error handling function to every PHP script. Though, this doesn't sound efficient.
This is more of a server level question, if you don't like the answer that Frankie provided in his comment. Without using set_error_handler there is no way (in PHP) to output all errors to a log file instead of the log.
If you are using Apache, you can do the following:
CustomLog "|/path/to/custom_log_script.php [OPTIONS]"
(note the pipe)
That will allow you to use a custom error log handler to control what does and doesn't wind up in the log files.
You can set a cron job to execute a php script read the error log file for new errors and store them in the database. The error log table won't be real time though but I think it shouldn't be too big a problem.
How would I go about changing where PHP logs it's syntax errors? I've got multiple people working on the same server, and I want to be able to send my own logs to a custom file so that I'm not looking at every one else's errors.
I can do this:
error_reporting(E_ALL);
ini_set('display_errors','On');
ini_set('error_log','path/to/mylogfile.log');
And that works for some errors, but for actual syntax errors, the logs are still being sent to the master /var/log/httpd/error_log. How do I make the syntax errors get sent to my custom log file?
Since the file cannot be correctly parsed, the ini_set function is not executed either and neither is the new error log set. You need to set php_value error_log /path/to/myfile.log in an .htaccess file or the global server config (I'm assuming that you're using Apache).
Given that syntax errors prevent PHP from running you will not be able to set log paths via PHP. It's a chicken before the egg situation.
Alternatives would be:
Change the error log at the webserver level
Enable output of error messages to the browser
I'd suggest the latter.
I have the following code:
<?php
if ($foo) {
echo $foo;
}
?>
However, my page is throwing a 500 internal server error (I know this generally means there's an error being logged and the page is aborting prematurely) I do not have access to the error log (as the host is logging to syslog).
I can fix it by doing the following:
<?php
if (isset($foo) && $foo) {
echo $foo;
}
?>
but that's not my question. Is there a server setting that would kill a page attempting to use an unset variable? AFAIK, it only logs a 'Notice', which is normally not enough to kill the page.
Here is the first bit of the phpinfo() output (disclaimer: I have no Windows + FastCGI setup experience)
Update
I added a custom error handler and simply output the $errno and $errstr. As expected, it was an E_NOTICE (8) with message 'Undefined variable'. I'm guessing the 500 internal error has something to do with how it's logging to the syslog.
Implement a custom error handler and you can do anything you'd like (mostly)!
In my experience 500th errors are usually caused by infinite loops ( either directly in code , or because of unending redirect ). Or it has something to do with display_errors setting on php.ini file.
If you have no access to server logs, i would recommend for you to use VirtualBox ( or some other virtualization tool ) and set up identical server environment in VM, and then see what exactly you get in the logs.
P.S. why cant you host your page on a normal NIX server with an up-to-date PHP version ?!
I dont know of any setting that would do that... I suspect something else is goign wrong after that, perhaps because the variable isnt set. Your best bet here is probably to do as David suggest and make a quick custom error handler so you can get some reporting on what is actually happening.
As an aside your host should be giving you some kind of access to the error logs even if he wants to send errors to syslog . I dont think ive ever been on a host that hasnt made error logs available. Id recommend switching hosts if you can. This is kind of something everyone expects...