Bug #27150

PHP errors not logged to webserver's error_log

Added by Christian Boltz over 8 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-05-30
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

I had a very interesting problem today: the BE login was impossible on a fresh Typo3 installation (4.5.2, but that doesn't really matter).

It turned out that someone changed the directory permission on the session.save_path directory, making it impossible to store the session. Normally (as in "some non-Typo3 PHP script") that results in an entry in the webserver's error log, which makes it quite easy to find the problem.

The problem: the PHP error message was only logged to the sys_log table, which is readable with the log module in the backend - IF you can login...

It would be a very good idea to log PHP errors to the webserver's error log, not (only) into a somehow hidden log table. The average server admin checks the error log and might not even be aware of the sys_log table.

A comment from Johan "Josso" Jensen on
http://de2.php.net/manual/de/function.set-error-handler.php
says that you should use error_log() inside the error handler:

     if (ini_get('log_errors'))
         error_log(sprintf("PHP %s:  %s in %s on line %d", $errors, $errstr, $errfile, $errline));

Note: I did not test this. The information about using error_log is just copy&paste from the php.net page ;-)

History

#1 Updated by Patrick Rodacker over 8 years ago

TYPO3 offers detailled control about the log configuration. Have a look at the settings

$TYPO3_CONF_VARS['SYS']['systemLog'] 
$TYPO3_CONF_VARS['SYS']['systemLogLevel']

in the All Configuration section of the install tool.

If you set them to

$TYPO3_CONF_VARS['SYS']['systemLog'] = 'error_log';
$TYPO3_CONF_VARS['SYS']['systemLogLevel'] = '0';

the log message should appear in the webservers log.

TYPO3 ships with an empty setting for $TYPO3_CONF_VARS['SYS']['systemLog'] as default so it could be discussed if the default value should be changed.

#2 Updated by Markus Klein over 8 years ago

Hi!

Definitely this has to be changed!
I ran into the same problem once. I discovered the reason, when I tried to access phpmyadmin which told me, that the session couldn't be created.

So my full +1.

Regards

#3 Updated by Gerrit Notifier over 8 years ago

[test for the core mailing list]

It makes sense to investigate

#4 Updated by Steffen Müller about 8 years ago

Confirmed

#5 Updated by Wouter Wolters about 5 years ago

  • Status changed from New to Needs Feedback
  • Is Regression set to No

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.2.9)?

#6 Updated by Steffen Müller about 5 years ago

  • TYPO3 Version changed from 4.5 to 6.2

Still valid for 6.2, tested with branch TYPO3_6-2 at 657e177f5404ed28eeb21bd4c1af76d0bdadd292 (2015/12/09)

I did a quick test on master at e0467960abe3e269c8bbc38135ff0c7245c2b5b3 (2015/12/09).
In opposite to 6.2, I get an exception in the browser:

Fatal error: Uncaught exception 'TYPO3\CMS\Core\Error\Exception' with message ' in /xxxxxx/typo3_src-master/typo3/sysext/core/Classes/Error/ErrorHandler.php on line 102
( ! ) TYPO3\CMS\Core\Error\Exception: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp/php/ ...

#7 Updated by Alexander Opitz over 4 years ago

  • Status changed from Needs Feedback to New

#8 Updated by Markus Klein almost 2 years ago

  • Status changed from New to Needs Feedback

This needs to be tested again.

Please make sure that "log_errors" is configured correctly in PHP settings.
PHP should then of course log all errors to the configured "error_log" destination. (Either apache error.log or dedicated FPM log or maybe an upstart log file)

#9 Updated by Riccardo De Contardi over 1 year ago

  • Status changed from Needs Feedback to Closed

No feedback since the last 90 days => closing this issue.

If you think that this is the wrong decision or experience the issue again and have more information about how to reproduce your problem, please reopen it or open a new issue with a reference to this one.

Thank you and best regards

Also available in: Atom PDF