date.timezone incorrect in error logs

[4u123]

I'm seeing a strange issue that only became apparent when looking in an accounts php error_logs. The date.timezone is correctly set in the server's php.ini to the appropriate time zone of the server - but all PHP log entries are displayed as UTC. This is happening on all our servers with all PHP versions.

I've looked into it and noticed there was a bug in older versions of PHP where the logging ignored the date.timezone setting - but that was back in version 5.3 and was apparently fixed. This is definitely a new issue. It has been working fine for some time until recently.

I have confirmed via phpinfo that the correct date.timezone is being used. It's just the error logs that seem to be producing entries in UTC.

I'm wondering if anyone else has experienced this same issue?

 

[cPanelMichael]

Hi @4u123,

I was unable to reproduce the behavior you described on a test server when taking the following steps:

1. Review the system time:

# date
Wed Aug 15 10:42:27 CDT 2018

2. Set the "date.timezone" php.ini directive using WHM >> MultiPHP INI Editor to "America/New_York" for PHP version 7.0.

3. Uploaded and accessed a test PHP script that errors out on a domain using PHP version 7.0.

4. Confirmed the error_log file uses the configured time zone:

[15-Aug-2018 11:44:31 America/New_York] PHP Parse error:

Can you verify which PHP handlers are assigned to the accounts you are testing this with?

Thank you.

 

[4u123]

All servers are using lsapi

 

[cPanelMichael]

All servers are using lsapi

Hello,

Are you also using PHP Selector (alt-php) with CloudLinux? If so, note the following information in the Configuring "Global” php.ini Options for all Alt-PHP Versions CloudLinux document:

date.timezone and error_log options are handled differently than the others. When these options are not in /etc/cl.selector/global_php.ini file, than values for the options will be taken from "native" php.ini file. And when the option is in php.ini for some Alt-PHP version already (and its value is not empty), than value from /etc/cl.selector/global_php.ini will be NOT applied.

Can you verify if this is applicable to your particular system? If not, feel free to open a support ticket and we can take a closer look to see what's happening.

Thank you.

 

[4u123]

No we've been using EA4 for some time now. We did previously use cl.selector but this is disabled when removing alt-php. It's also important to mention that since switching to EA4 and setting the date.timezone - the error logs have been producing entries with the correct timezone until recently. Only regular EA4 / cpanel updates can have had an influence on this situation. Nothing else has changed. I also note that there have been significant changes to the EA4 PHP configuration in recent cpanel versions.

I'd be interested to know under what circumstances the timezone in an error_log can be different to that of the PHP environment. I've done some research but so far not found anything. I'll keep digging.

 

[cPanelMichael]

Hello @4u123,

I'm happy to take a deeper look as well, but I'll need some additional information about how the affected system is configured. You noted using LSAPI as the PHP handler for the EA-PHP packages. I've setup a system with that configuration, however by default it logs the PHP errors to /usr/local/apache/logs/error_log. EX:

[Tue Aug 21 10:55:22.477458 2018] [lsapi:error] [pid 15311:tid 139887705560832] [client 1.2.3.4:59417] [host domain.tld] Backend fatal error: PHP Fatal error:  Cannot divide by zero in /home/username/public_html/test.php on line 3\n

Can you let me know of any specific changes you've made to the PHP configuration on the affected system (as it relates to PHP error logging or otherwise) so that I can replicate the issue?

Thank you.

 

[4u123]

I appreciate you taking the time to do that.
We haven't done anything special. All PHP errors produced by scripts in customer accounts are saved to a file named error_log at the location of wherever the script was running from in the users home directory.

That's the default behaviour and has been for at least a decade as far as I know. We haven't done anything to force that. The error log you mention is the Apache log and for as long as we have been using cpanel - PHP errors have never been logged into that file.

 

[cPanelMichael]

Hi @4u123,

It looks like the global Apache error log was utilized for PHP error logging on my test system because mod_suexec was not installed (PHP was running as the Apache user). I installed it (yum install ea-apache24-mod_suexec) and now PHP errors are logged to the individual error_log files within the document root of the PHP script.

With that issue solved, I utilized the steps referenced in my earlier post for an account using PHP version 7.1 (and mod_lsapi as the handler) this time. Before making the change via WHM >> MultiPHP INI Editor, here's an example of the entry in the error_log file:

[22-Aug-2018 14:38:22 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function asd() in /home/cptest85/public_html/test2.php:2

After making the change, here's an example of the entry in the error_log file:

[22-Aug-2018 10:42:19 America/New_York] PHP Fatal error:  Uncaught Error: Call to undefined function asd() in /home/cptest85/public_html/test2.php:2

There must be some other mod_lsapi configuration value or php.ini setting that's leading to the issue you are facing. I've been unable to reproduce the behavior on a test system, but feel free to open a support ticket if you'd like for us to investigate further.

Thank you.