date.timezone Fatal after PHP update 7.9.7

SuiteCRM Forum - English Language SuiteCRM General Discussion
1

Recently needed to update to 7.9.7 because workflows was not working in 7.9.6. This required me to updat PHP which is now Apache/2.4.23 (Fedora) PHP/7.1.8

I am still getting a error every minute…

Mon Nov 13 17:27:01 2017 [20389][-none-][FATAL] Configuration variable date.timezone is not set, guessed timezone UTC. Please set date.timezone=“UTC” in php.ini!

I have updated the php.ini in the root of the suite install to date.timezone= “America/New_York” I have updated the CLI in /etc/php7/php.ini as well to the same. I tried it with both “” and without.

I have varified my date of Server and it is correct. I have verified the user date and it is correct. I have verified the Phpinfo () and it is correct showing

date/time support enabled
timelib version 2017.05beta9
“Olson” Timezone Database Version 2017.3
Timezone Database internal
Default timezone America/New_York
Directive Local Value Master Value
date.default_latitude 31.7667 31.7667
date.default_longitude 35.2333 35.2333
date.sunrise_zenith 90.583333 90.583333
date.sunset_zenith 90.583333 90.583333
date.timezone America/New_York America/New_York

Any thoughts on trying to troubleshoot resolving the date.timezone fatal error?

2

The problem is that cron is running from a different PHP (called CLI), and thus from a different php.ini.

You can try adding that setting to the cron job definition by passing it from the command-line into PHP (-d option)

Something like this:


*    *    *    *    *     cd /path/to/suitecrm; /path/to/php-cli/php -f cron.php -d date.timezone="Europe/Lisbon" > /dev/null 2>&1

You can ask your hosting for details (correct paths) or for alternatives, if this does not work. It is their responsibility to provide you with a way to correctly set options for CLI PHP.

3

Or find out the location of your php.ini for cli by entering at the command prompt

php --ini

and change accordingly

4

Makes sense but I need to clarify one item.

As originally stated I have updated the CLI PHP.ini but was still getting the error.

Do I place this cron directive in the same location as the scheduler cron is running? Will this new cron address the issue even though originally I had changed the date.timezone in the CLI which for me is found in the /etc/php7/php.ini? or is this overiding it with the cron running instead of the php.ini directive?

5

OK so I think I have this correct for my main database but it throwing errors for my dev site on the same server.

Any chance you see something that might be causing this?

Warning: Declaration of SugarDateTime::setTime($hour, $minute, $sec = 0) should be compatible with DateTime::setTime($hour, $minute, $second = NULL, $microseconds = NULL) in /var/www/sites/suitecrm_dev/rp/include/SugarDateTime.php on line 692

Warning: Declaration of SugarEmailAddress::save($id, $module, $new_addrs = Array, $primary = ‘’, $replyTo = ‘’, $invalid = ‘’, $optOut = ‘’, $in_workflow = false) should be compatible with SugarBean::save($check_notify = false) in /var/www/sites/suitecrm_dev/rp/include/SugarEmailAddress/SugarEmailAddress.php on line 1162

Warning: session_start(): Cannot start session when headers already sent in /var/www/sites/suitecrm_dev/rp/include/MVC/SugarApplication.php on line 619

Warning: Cannot modify header information - headers already sent by (output started at /var/www/sites/suitecrm_dev/rp/include/SugarDateTime.php:692) in /var/www/sites/suitecrm_dev/rp/include/utils.php on line 2802

Warning: session_destroy(): Trying to destroy uninitialized session in /var/www/sites/suitecrm_dev/rp/include/MVC/SugarApplication.php on line 124

It seems to be a date configuration issue.

6

Hi, I think your error_reporting is set incorrect. Unfortunately the code of SuiteCRM still needs some clean up to get rid of all the warnings. Please check your error_reporting in php.ini and try the following value:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE & ~E_WARNING

Restart your nginx/apache/php_fpm after changing the value.

7

Turned on error reporting error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE & ~E_WARNING
In the /etc/php7/php.ini file and the error_log is showing

[proxy_fcgi:error] [pid 937] [client ip:6987] AH01079: failed to make connection to backend: httpd-UDS
[Wed Nov 15 08:36:31.904435 2017] [proxy:error] [pid 960] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php-fpm/www.sock (*) failed

I suspect it is because php-fpm does not auto restart but I don’t know how to check or restart. Thoughts?

8

Hi, list your services by

service --status-all

See if you can find a service by the name of php-fpm or php7.1-fpm. Then

service php-fpm restart

Also check your logs, like

/var/log/php-fpm.log
9

services only show configured devices
lo eth0

I have attempted restart of php-fpm

php-fpm.log

{15-Nov-2017 09:26:28] ERROR: FPM initialization failed
[15-Nov-2017 13:48:58] ERROR: unable to bind listening socket for address ‘/run/php-fpm/www.sock’: No such file or directory (2)
[15-Nov-2017 13:48:58] ERROR: FPM initialization failed

10

@tseward I never installed using php-fpm, but maybe you can look into which modules you’re loading. You might have required modules missing, and that could be the cause of these errors.

On Ubuntu 16.04 with PHP 7.0 I typically use these

apt install zip unzip php-mbstring php7.0-mbstring php-gettext php-xml-parser php7.0-zip php7.0-imap php7.0-gd php7.0-curl sendmail phpmyadmin

You probably need to adapt that for PHP 7.1, but it can serve as a guide.

11

Hi,

this is a system configuration issue.

Please check if the directory /run/php-fpm exists, if not create it and make sure the system user that runs php-fpm (usually “www-data” or “www”) can write in this directory.