Php systemctl issue after firmware update And kernel patch

V

vancanneyt

Verified User
Joined
Dec 13, 2012
Messages
92
After the kernel patches released by CentOS, serious issues rose with systemctl and php.
Initial issues described in this thread: http://forum.directadmin.com/showthread.php?t=55775&p=285648#post285648
I had to manually start the process from command line (/usr/local/php72/sbin/php-fpm72) to get php-fpm running. With systemctl it keeps crashing minutes after it loads (see thread). Logs don’t lead me to where the problem is
It got to my attention that at midnight when logrotate happens, php-fpm rellad also failed through systemctl
Code: 
2018:01:06-00:11:01: Error reloading service php-fpm72 : uid 0 gid 0 : /usr/bin/systemctl reload php-fpm72.service        >/dev/null 2>/dev/null

When manually running command systemctl reload php-fpm72.service it gives: “job for php-fpm72 invalid

Also performed set_permissions to exclude any permission problem, same result

Any help is welcome on how to resolve this rather serious issue.
 
Last edited:
Could the issue be spesific for PHP 7.2? Because I have upgraded kernel on CentOS 7 with PHP-FPM 7.1 and I have not yet seen any problems.
 
Why didn’t I try that ��
Downgraded to 7.1.13, this was successful (thanks Ditto).
So it’s an issue with php 7.2 and 7.2.1 ��
 
After some more digging it seems the failure happens when exif is enabled. This for most recent php versions 7.0, 7.1 and 7.2
 
I am sorry you still is affected by this. This is confusing, because I am also running CentOS 7.4 and newest PHP 7.1.13, and I also has compiled PHP with exif support, and still I have not experienced this. But maybe there is other differences in our setups...

I looked at PHP changelogs for exif, they fixed a versioning bug in PHP 7.0.26 and 7.1.12: http://www.php.net/ChangeLog-7.php#7.1.13

Code: 
Fixed bug #75301 (Exif extension has built in revision version).

So now it should be dymamic versioning corresponding with the PHP version you are running. Is your Exif version in a PHP info page the same as the PHP version your are running? If not then maybe you have installed exif in a different way (other way then adding --enable-exif to the configure.php file) and it is not updated during PHP recompile?
 
Its a brand New server (month old) and before I moved sites over it was configured with php 7.2 with exif enabled. Immediately after kernel patch install the php-fpm crashed every minute. Something then broke. When downgrading to 7.1, I hadn’t enabled exif again so the issue was resolved. Re-enabling exif and recompiling php again, the issue was there again. So reverted configuration.php back without enable exif and rebuild php to make it work again.
I couldn’t check phpinfo to check version cuz of the continually crashing

When building php, when it indicates ‘enabling php-fpm71.service in systemctl’, it hangs there with timeout and is the start of the continuesly crash and restart of service. That doesn’t relate in anything to exif. PHP Startup should have at least logged that but nothing that pointed in that direction.

Plus, php-fpm could be started directly if you ran the executable from command line which stopped the crashes. But all commands to systemctl to either stop start reload the php-fpm service failed.
 
Last edited:
That's a weird issue.. What is exactly in your custom/fpm/configure.php72 file?

I just recompiled 7.2 with exif enabled (forgot to copy custom things from configure.php71 to configure.php72:rolleyes:) and don't have these issues. I noticed there are a couple changes between configure.php71 & configure.php72 though.
 
The custom configure was only with the added —enable-exif at the end of the file. Php compiling completed building. Strange thing is that I could start php-fpm from command line without crashing, only that didn’t work through systemctl.
 
Nginx is configured as standalone HTTP server but don’t think it has something to do with that.
 
Had another try after the latest linux_firmware update
Again stuck at enabling it in systemd when exif is enabled in PHP (7.1 and 7.2)
Code: 
Created symlink from /etc/systemd/system/multi-user.target.wants/php-fpm72.service to /etc/systemd/system/php-fpm72.service.
Job for php-fpm72.service failed because a timeout was exceeded. See "systemctl status php-fpm72.service" and "journalctl -xe" for details.
But PHP does work:
Code: 
[21-Jan-2018 14:17:15] NOTICE: fpm is running, pid 17444
[21-Jan-2018 14:17:15] NOTICE: ready to handle connections
[21-Jan-2018 14:18:45] NOTICE: Terminating ...
[21-Jan-2018 14:18:45] NOTICE: exiting, bye-bye!
[21-Jan-2018 14:18:45] NOTICE: fpm is running, pid 17550
[21-Jan-2018 14:18:45] NOTICE: ready to handle connections
[21-Jan-2018 14:20:15] NOTICE: Terminating ...
[21-Jan-2018 14:20:15] NOTICE: exiting, bye-bye!
But the systemd service is not:
Code: 
Jan 21 14:20:15 localhost systemd: php-fpm72.service start operation timed out. Terminating.
Jan 21 14:20:15 localhost systemd: Failed to start The PHP FastCGI Process Manager.
Jan 21 14:20:15 localhost systemd: Unit php-fpm72.service entered failed state.
 
quick update, found out that zend was enabled so that was disabled and updated to 7.1.14 that was just released. This time no more systemd timeout after install.
 
ran into the issue again today with PHP 7.1.15. Through custom build plugin I customized the PHP build script to add enable-exif, than ran the .build php script and the issue was there again. When I revert the config file in the custom build plugin and manually add it to the /usr/local/directadmin/custombuild/configure/fpm/configure.php71 script at the end --enable-exof and do a build php again, the issue is gone. Could this be a bug in the custom build plugin script?
 
the same problem

vancanneyt said:
ran into the issue again today with PHP 7.1.15. Through custom build plugin I customized the PHP build script to add enable-exif, than ran the .build php script and the issue was there again. When I revert the config file in the custom build plugin and manually add it to the /usr/local/directadmin/custombuild/configure/fpm/configure.php71 script at the end --enable-exof and do a build php again, the issue is gone. Could this be a bug in the custom build plugin script?
Click to expand...

hi,

had the same problem. Maybe it's time to look at this as a bug
 
Can confirm it’s still present when doing it through the custumbuild plugin. I still edit the configure file manually through ssh to avoid these problems
 
You must log in or register to reply here.
Back
Top