Resolved php7.2 php-fpm.sock file error

[Franco]

Hello,
after the announced support for php7.2 I went ahead and converted a few websites to use 7.2 (from 7.1). My configuration is nginx/php-fpm and I am running the latest 17.5.x under CentOs 7.4.

Things went fine for a few websites (except for those which do not support yet that version for theme or plugin issues), but on a couple of those I had what I think might just be a configuration issue. After converting to 7.2 the website goes inaccessible and the following message appears in /var/log/messages:

*960742 connect() to unix:///var/www/vhosts/system/domain/php-fpm.sock failed (2: No such file or directory) while connecting to upstream

In fact the php-fpm.sock file is not there. It is there on the working websites and also for those running 7.1.
And /var/vhosts/system/domain/conf/vhost_nginx.conf looks ok to me, at least it still requires the php-fpm.sock file to be in the same location, but the file is not.

Why would that config fail? Can I just copy the file to the target folder?

Thank you in advance for any help.

Regards
Franco

 

[Bitpalast]

What is the output of
# service plesk-php72-fpm status
?

 

[Franco]

Hi,
the result of the status command is given below, but first I would like to report that sometimes later (less than 1 hour) I got a system crash and had to reboot from the management console (Plesk was not available and SSH was not available). It looks like a hardward problem, but not sure yet.

However, after reboot things were unstable and got frequent websites not responding and mysql not being available (with Zend messages about error 2002), first time I see those.

In particular:

ERROR: Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] Connection refused
Additionally, an exception has occurred while trying to report this error: Zend_Exception
No entry is registered for key 'translate' (Abstract.php:144)


In /var/log/messages I saw that all those websites (and only those) that were configured with php 7.2 had one or two tables corrupted, such as:

140543869278976 [ERROR] mysqld: Table './goupars@002ddb_a/pwY8bR88_itsec_lockouts' is marked as crashed and should be repaired

I then run:
plesk repair all -n
which did not find much, but after another reboot I could connect to Plesk.
I subsequently tried to find and repair all those crashed tables.
My system remains heavily unstable and now, again, no access to Plesk Panel
Is there a correlation between all these facts? Is plesk php7.2 compatible with MariaDB?

Here's the status anyway:

Redirecting to /bin/systemctl status plesk-php72-fpm.service
● plesk-php72-fpm.service - The PHP 7.2.0 FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/plesk-php72-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2017-12-07 17:38:43 CET; 14min ago
Main PID: 1015 (php-fpm)
Status: "Processes active: 0, idle: 490, Requests: 63, slow: 0, Traffic: 0req/sec"
CGroup: /system.slice/plesk-php72-fpm.service
├─1015 php-fpm: master process (/opt/plesk/php/7.2/etc/php-fpm.conf)

..followed by a long list of what appear to be pids with php-fpm: pool domainabc.com (several per domain, maybe because I configure 40 max_children)

..and then:
systemd[1]: Starting The PHP 7.2.0 FastCGI Process Manager...
systemd[1]: Started The PHP 7.2.0 FastCGI Process Manager.

 

[Franco]

Another thing I noticed is the free swap space to 0, but perhaps that's normal?

KiB Mem : 3873820 total, 110224 free, 3258864 used, 504732 buff/cache
KiB Swap: 2097148 total, 0 free, 2097148 used. 14416 avail Mem​

Here’s is my disk status, looks normal to me:

# df -h

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-root 118G 83G 35G 71% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 17M 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda1 497M 237M 261M 48% /boot
tmpfs 379M 0 379M 0% /run/user/0​

 

[Franco]

I guess this was due to the memory issue resolved here Resolved - php-fpm memory leak? and it did not have anything to do with php 7.2 per se. I close it then.