PHP's configuration setting 'error_log' is not working

Question

What am I doing wrong here?

I have error_log set in the .ini file along with error_reporting = E_ALL | E_STRICT.

What else am I missing? This usually gave it to me. I want this set in the .ini file and not in my scripts.

Another interesting thing that is happening is that when I purposefully try and throw an error in one of my scripts, Apache restarts over and over again.

---

This is my event log after one error. Look at the timestamp.

Wed Nov 04 19:34:23 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Wed Nov 04 19:34:23 2009] [notice] Server built: Sep 28 2009 22:41:08
[Wed Nov 04 19:34:23 2009] [notice] Parent: Created child process 1700
[Wed Nov 04 19:34:23 2009] [notice] Child 1700: Child process is running
[Wed Nov 04 19:34:23 2009] [notice] Child 3008: Released the start mutex
[Wed Nov 04 19:34:23 2009] [notice] Child 1700: Acquired the start mutex.
[Wed Nov 04 19:34:23 2009] [notice] Child 1700: Starting 64 worker threads.
[Wed Nov 04 19:34:23 2009] [notice] Child 1700: Starting thread to listen on port 80.
[Wed Nov 04 19:34:24 2009] [notice] Child 3008: All worker threads have exited.
[Wed Nov 04 19:34:24 2009] [notice] Child 3008: Child process is exiting
[Wed Nov 04 19:34:53 2009] [notice] Parent: child process exited with status 128 -- Restarting.
[Wed Nov 04 19:34:53 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Wed Nov 04 19:34:53 2009] [notice] Server built: Sep 28 2009 22:41:08
[Wed Nov 04 19:34:53 2009] [notice] Parent: Created child process 3656
[Wed Nov 04 19:34:53 2009] [notice] Child 3656: Child process is running
[Wed Nov 04 19:34:53 2009] [notice] Child 3656: Acquired the start mutex.
[Wed Nov 04 19:34:53 2009] [notice] Child 3656: Starting 64 worker threads.
[Wed Nov 04 19:34:53 2009] [notice] Child 3656: Starting thread to listen on port 80.
[Wed Nov 04 19:34:53 2009] [notice] Parent: child process exited with status 128 -- Restarting.
[Wed Nov 04 19:34:54 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Wed Nov 04 19:34:54 2009] [notice] Server built: Sep 28 2009 22:41:08
[Wed Nov 04 19:34:54 2009] [notice] Parent: Created child process 3980
[Wed Nov 04 19:34:54 2009] [notice] Child 3980: Child process is running
[Wed Nov 04 19:34:54 2009] [notice] Child 3980: Acquired the start mutex.
[Wed Nov 04 19:34:54 2009] [notice] Child 3980: Starting 64 worker threads.
[Wed Nov 04 19:34:54 2009] [notice] Child 3980: Starting thread to listen on port 80.
[Wed Nov 04 19:34:54 2009] [notice] Parent: child process exited with status 128 -- Restarting.
[Wed Nov 04 19:34:54 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Wed Nov 04 19:34:54 2009] [notice] Server built: Sep 28 2009 22:41:08
[Wed Nov 04 19:34:54 2009] [notice] Parent: Created child process 1600
[Wed Nov 04 19:34:54 2009] [notice] Child 1600: Child process is running
[Wed Nov 04 19:34:54 2009] [notice] Child 1600: Acquired the start mutex.
[Wed Nov 04 19:34:54 2009] [notice] Child 1600: Starting 64 worker threads.
[Wed Nov 04 19:34:54 2009] [notice] Child 1600: Starting thread to listen on port 80.
[Wed Nov 04 19:34:55 2009] [notice] Parent: child process exited with status 128 -- Restarting.
[Wed Nov 04 19:34:55 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Wed Nov 04 19:34:55 2009] [notice] Server built: Sep 28 2009 22:41:08
[Wed Nov 04 19:34:55 2009] [notice] Parent: Created child process 1068
[Wed Nov 04 19:34:55 2009] [notice] Child 1068: Child process is running
[Wed Nov 04 19:34:55 2009] [notice] Child 1068: Acquired the start mutex.
[Wed Nov 04 19:34:55 2009] [notice] Child 1068: Starting 64 worker threads.
[Wed Nov 04 19:34:55 2009] [notice] Child 1068: Starting thread to listen on port 80.
[Wed Nov 04 19:34:55 2009] [notice] Parent: child process exited with status 128 -- Restarting.
[Wed Nov 04 19:34:55 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Wed Nov 04 19:34:55 2009] [notice] Server built: Sep 28 2009 22:41:08
[Wed Nov 04 19:34:55 2009] [notice] Parent: Created child process 3220
[Wed Nov 04 19:34:56 2009] [notice] Child 3220: Child process is running
[Wed Nov 04 19:34:56 2009] [notice] Child 3220: Acquired the start mutex.
[Wed Nov 04 19:34:56 2009] [notice] Child 3220: Starting 64 worker threads.
[Wed Nov 04 19:34:56 2009] [notice] Child 3220: Starting thread to listen on port 80.

---

_{This has been asked 1000 times and I have browsed through the different posts before posting this, but I have not found an answer. As long as I have been programming with PHP, this have always been a nightmare to get working.}

Unseasoned

Related, for locating the PHP error log: Where does PHP store the error log? (PHP 5, Apache, FastCGI, and cPanel) (despite the over-specific title). – Unexampled

Answer 1

Check PHP-FPM is not explicitly setting error_log:

Make sure the file /etc/php-fpm.d/www.conf does not contain php_admin_value settings for error_log. Search for the following and comment them out using a semi-colon:

; NOTE: If these are set, ini_set('error_log', 'path') will have no effect
; inside your php code, and this will be forced to be the value always.
; php_admin_value[error_log] = /var/log/php-fpm/www-error.log
; php_admin_flag[log_errors] = on

Then restart php-fpm:

systemctl restart php-fpm

Check Apache .htaccess files are not setting the error_log value using

php_admin_value settings in the Apache configuration files cannot be overridden, so make sure you don’t have any php_admin_value for the error_log setting in the Apache configuration files. Also check for php_value settings just in case.

PHP Website - How to change configuration settings

Faceplate

Lifesaver! This solved it for me after spending hours troubleshooting. Thanks! – Jaggery

Answer 2

Flimm's Troubleshooting Guide

Here is my troubleshooting guide to error_log() calls not working.

1. Look at your server's configuration to find out where the default error log file is. This depends on which server you're using. To get you started, have a look at Apache's ErrorLog and LogLevel options if you're using Apache or Nginx's error_log option if you're using Nginx. Make sure it is set to a file. If you're using a tool like Valet, note that it's using server software like Nginx behind the scenes.

2. Check the permissions of your server's error log file. On Unix-like systems, it should be writeable by the correct user and group, and the permissions of the parent directory and all its ancestors need to be correct as well. Use chmod and chown. On Debian and Ubuntu, the files and directories need to be have the user or group set to www-data.

3. Check the configuration of PHP in the .ini files. Specifically, check for log_errors = On and error_reporting = E_ALL and error_log = /var/log/apache2/php_errors.log (see docs for log_errors, error_reporting and error_log configuration settings). To find the .ini file, look at the output of phpinfo();. If error_log is not set, by default it goes to the error log for the server, mentioned in the previous steps. If error_log is set to a file, it should already exist and be writeable, just like in previous steps. Remember to restart the server after configuration changes.

4. Check that PHP's settings aren't being changed by server configuration. Your server's configuration (even .htaccess) can change PHP configuration settings. In Apache, this is done using php_admin_value and php_admin_flag (docs). For instance, you may find in your .htaccess file this line: php_admin_flag[log_errors] = off. Remember to restart the server after configuration changes.

5. Check that AppArmor isn't causing permission issues. (AppArmor is usually installed in Debian, Ubuntu and similar distros.) To check if AppArmor is enabled, run aa-enabled . Find error messages by searching for apparmor in the output of sudo journalctl or in the file /var/log/kern.log or similar. You can use aa-notify to get desktop notifications for AppArmor DENIED messages. See AppArmor documentation.

6. Check that SELinux isn't causing permission issues. (SELinux is usually installed on RHEL, Fedora, and similar distros.) To check if SELinux is enabled, run sudo sestatus . See this answer for more details.

At this point, you should be able to create a test file test.php with the contents <?php error_log("test");, restart your server, and open the URL in your browser, and you should be able to see test in your error log (either the server's, or the one specified by error_log = ). But keep reading.

7. Check that PHP's settings aren't being changed at run-time. The log_errors option can be changed at runtime by running ini_set('log_errors', 1);, and so can the other configuration options error_reporting and error_log. Also note there is a special error_reporting() PHP function which changes the configuration at run-time. Search your code-base for any invocations of ini_set or error_reporting. WordPress for example does run these depending on the value of WP_DEBUG.

Other things to look at:

• If you're using Xdebug, you can use the setting xdebug.force_error_reporting to enable error reporting, by setting to this value: xdebug.force_error_reporting = 2147483647
• It may take a few seconds for error_log(); to flush the write to the log file.

Hadst

And one more thing: if you are accessing an https: website, then you need to look in the ssl_error_log file and not the error_log file. – Resilient

@Resilient Are you talking about nginx? – Hadst

My experience was with apache. I spent ages trying to figure out why nothing was being logged to the error_log file any more, and then realised that it was all going to ssl_error_log (although some installs send everything to error_log whether it is SSL or not. – Resilient

In my case the application itself had it's own log files. – Discovert

@Resilient There isn't an Apache setting or a PHP setting called ssl_error_log that I can find. Are you talking about a file named ssl_error_log ? – Hadst

@Hadst yes, that is the name of a file, not a setting – Resilient

Answer 3

You also need to set log_errors = On in file php.ini.

Dotty

Hi Chaos, thanks. I already have that set to On. Am I missing anything else? – Unseasoned

Just restart the server. – Ferd

@Ferd Can you explain why did it help and why it was broken? – Theme

Where is file php.ini located? In /etc/php/7.4/apache2/php.ini? – Unexampled

OK, one way is the line with "Loaded Configuration File" in the output from phpinfo(). From the command line: php -r "phpinfo();" | grep "Loaded Configuration File" (sample output: Loaded Configuration File => /etc/php/7.4/cli/php.ini). In a web context: If test page file test.php exist it contains a call to phpinfo() - e.g., URL http://localhost/test.php (sample output: /etc/php/7.4/apache2/php.ini). – Unexampled

Answer 4

In case anyone else is having trouble getting their local development environment to log errors, here's what fixed it for me:

On Windows, error_log must be set to the complete path to the log for error_log() to work (error_log = c:\apache\php_errors.log). However, if error_log = php_errors.log with no path, php will still be able to log startup errors such as

PHP Startup: Unable to load dynamic library 'ext\php_mysqli.dll' - The specified module could not be found

Olin

I specified full path and did not create the file in advance. When I restart WAMP the log file is created but WAMP display a yellow icon and localhost won't load. Any ideas what that might be? When I comment out error_log everything is fine but PHP errors appear in the Apache log. – Vue

Answer 5

The problem I ran into was that the error log I had designated was write-protected. All my .htaccess settings were correct, but PHP just couldn't write to the error log, because it didn't have any permissions. This fixed it right up for me:

chmod 777 watermellon-app-errors.log

Obviously, you're going to want to change the .log part to whatever file you're using for a log.

Telekinesis

Yes, you're correct. Of course, 644 might not be enough if the file's owner is someone else. You could use 777 to test it, and then lower permissions to see what works. – Telekinesis

In my case, I needed 646.. just FYI in case someone else runs into a problem like me – Declaim

On Mac OS, I had to use 666 since the normal files are set up as root:wheel I probably could have left it 646 since I think apache is running as "_www" by default. – Archival

chmod 777 = "sets permissions so that, (U)ser / owner can read, can write and can execute. (G)roup can read, can write and can execute. (O)thers can read, can write and can execute.". How secure is that? – Unexampled

Answer 6

If the error_log directive is set, the file will be used for recording PHP errors. When it is not set, errors will be logged to the Apache log. Take a look at error_log.

The error_log file and the directory it's in must be writable by the user that Apache is running under. If the file isn't being created, it's probably due to a permissions issue.

I don't know for sure why Apache would be crashing on you, but I'm guessing it's a permissions issue of some sort.

Susurration

Answer 7

I don't understand why, but the error log is now working. Here is what I did.

I gave up and commented back out the error_log directive and closed the ini file. I ran the script with the parse error to see if Apache would still crash and I got the PHP error in the log file. This is freaky, because the ini file no longer has error_log enabled and my script is not using ini_set().

Unseasoned

This is more a question than an answer. Stack Overflow is not a forum. – Unexampled

Answer 8

If you are using Fedora, SELinux (enabled by default) will prevent Apache / httpd from appending errors to your log file even when your file is specified in file php.ini and its containing directory has all permissions allowed.

You can see if this is happening by looking at your system log file in /var/log/messages

The ideal solution is to configure SELinux to allow access to the log file.

The quicker solution is to disable SELinux in /etc/selinux/config by setting SELINUX to disabled.

You'll need to reboot your system after doing this for the change to take effect.

Raney

The advice you gave actually has a website to stop that advice being given. stopdisablingselinux.com – Legacy

I know, hence my writing "ideal." I'm not yet convinced that a home user working locally needs SELinux turned on. – Raney

If the people at SElinux would stop breaking everything people could bother to use it. Even an SElinux log to say, "Hey, I just blocked this too. This is how you can enable it if you want." would be really helpful. As it is there's no way of knowing why it's broke until you say, it's probably SElinux because they break everything. Basically anything broken, I would look to SElinux until I eventually just gave up because it was taking hours out of my life just diagnosing that it was SElinux or searching for the obscure command or setting to let this instance through. – Derzon

Answer 9

In my case, on a CentOS development server, after a full yum update, the permission on /var/log/http was changed to 700 and the user to 'root', so the user 'apache' wasn't able to enter or write into it.

It was still able to write into the existing file /var/log/httpd/error.log, but it wasn't able to create a new file, as I use date-suffixed log files.

Issuing the command

chown apache /var/log/httpd

solved the problem.

Vulcanize

chmod 700 = "Sets permissions so that, (U)ser / owner can read, can write and can execute. (G)roup can't read, can't write and can't execute. (O)thers can't read, can't write and can't execute." – Unexampled

Answer 10

For further debugging: phpinfo();

It shows the current error_log setting, next to the error_log value in phpinfo() and can be useful when a vhost isn't logging.

I ended up here after that setting got overridden from file php.ini and the vhost. I ended up logging to syslog.

Pettaway

cheers for the formating and spelling update @PeterMortensen. I've updated it to specify that the error_log value is found under error_log. I'm not sure how much value was gained by this, however thanks for the formating and spelling update. – Pettaway

i was sure i was looking at the right error log, and so never bothered to check phpinfo -- i finally gave up and tried it after i saw you mention vhost. of course, there it was, the path to the real log. – Aphesis

Answer 11

For me, manually creating the file, /var/log/php_error.log, solved the issue:

1. In file php.ini, configure log to file

   log_errors = On
   error_log = /var/log/php_error.log
   

2. Restart Apache

   sudo systemctl restart apache2
   

3. Create the log file, for example:

   sudo touch /var/log/php_error.log
   

4. Give the correct rights (owner must be Apache)

   sudo chown www-data:root /var/log/php_error.log
   

   (And if not already set)

   sudo chmod 0644 /var/log/php_error.log
   

5. Test this way, for example:

   sudo vim /var/www/.../index.php
   

   <html>
       <body>
           PHP file:
           <?php
               echo "Hello, World!";
               trigger_error("User error in PHP", E_USER_ERROR);
           ?>
       </body>
   </html>
   

6. Check the error is written

   sudo less /var/log/php_error.log
   

Evangelina

Thank you @Peter Mortensen for making my answer clearer and well-formatted! – Evangelina

Answer 12

As bradym said, check whether you have write permissions to the directory where you PHP error log is located for the Apache user. If you created a log file with written permissions it's not enough; the directory should have them too.

Surfing

Answer 13

The error_log = "C:\php\Log\error.log" line was not working for me either. The solution for me was that you shouldn't create the error.log yourself, because PHP will do it for you. See the PHP message board. I'm using PHP 5.2 on a Windows Server 2008 server.

Leavetaking

Answer 14

I had the same issue and fixed it by doing this:

chmod 0777 -R /var/log/apache2
apachectl restart

I think PHP runs as user www-data while access to /var/log/apache2 is limited to root. So, this fixes it.

Harwin

Answer 15

This did the trick for me.

setsebool -P httpd_unified 1

Please note, this would be the preferred method below to try first:

semanage fcontext -a -t httpd_sys_rw_content_t 'errorLogNameHere.error.log
restorecon -v 'errorLogNameHere.error.log'

This answer was derived from the logs from executing this command line:

journalctl -xe

Further information on the system I was running on:

PHP 7.0 and CentOS 7

I am not sure if it's not obvious, but the issue was Apache's configuration to writing files. I did try chmod 777, chmod a+w on the logging directory, but this didn't work for me.

Roborant

But chmod a+w is not the same as chmod 777(?). – Unexampled