I had a problem on my main php server, wherein the main php5-fpm process would be killed by an HUP signal. After the main process would be killed it would fail to respawn. Since each child process is allowed only to server a certain number of requests, they would eventually die without spawning any other child process. This would cause the server to die and my users would receive a 502 response from the server. I was initially able to solve this issue by have a cron that would check the thread count of PHP processes and then restart if its less than 5.
Sep 14 11:41:41 ubuntu kernel: [ 3699.092724] init: php5-fpm main process (3592) killed by HUP signal
Sep 14 11:41:41 ubuntu kernel: [ 3699.092740] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.160940] init: php5-fpm main process (3611) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.160954] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.216950] init: php5-fpm main process (3619) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.216966] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.283573] init: php5-fpm main process (3627) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.283590] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.337563] init: php5-fpm main process (3635) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.337579] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.385293] init: php5-fpm main process (3643) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.385305] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.430903] init: php5-fpm main process (3651) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.430913] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.482790] init: php5-fpm main process (3659) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.482800] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.532239] init: php5-fpm main process (3667) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.532249] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.595810] init: php5-fpm main process (3675) terminated with status 78
Sep 14 11:41:42 ubuntu kernel: [ 3699.595825] init: php5-fpm main process ended, respawning
Sep 14 11:41:42 ubuntu kernel: [ 3699.648253] init: php5-fpm main process (3683) terminated with status 78
Sep 14 11:41:42 ubuntu0 kernel: [ 3699.648265] init: php5-fpm respawning too fast, stopped
My upstart script config
# php5-fpm - The PHP FastCGI Process Manager
description "The PHP FastCGI Process Manager"
author "Ondřej Surý <ondrej#debian.org>"
start on runlevel [2345]
stop on runlevel [016]
# Precise upstart does not support reload signal, and thus rejects the
# job. We'd rather start the daemon, instead of forcing users to
# reboot https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1272788
#
#reload signal USR2
pre-start exec /usr/lib/php5/php5-fpm-checkconf
respawn
exec /usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf
After searching the internet was finally able to get a solution to this by modifying the upstart script of php5-fpm in /etc/init/php5-fpm.conf
# php5-fpm - The PHP FastCGI Process Manager
description "The PHP FastCGI Process Manager"
author "Ondřej Surý <ondrej#debian.org>"
start on runlevel [2345]
stop on runlevel [016]
# Precise upstart does not support reload signal, and thus rejects the
# job. We'd rather start the daemon, instead of forcing users to
# reboot https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1272788
#
#reload signal USR2
pre-start exec /usr/lib/php5/php5-fpm-checkconf
pre-start exec /bin/bash /etc/init/php5-fpm.sh
post-start exec /bin/bash /etc/init/php5-fpm-onstart.sh
respawn
exec /usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf
So added additional scripts pre-start and post-start in the php5-fpm.conf. The pre-start script is
#!/bin/bash
rm /var/run/php5-fpm.pid
rm /var/run/php5-fpm.sock
CHILD_PIDS_FILE="/var/run/php5-fpm-child.pid"
CHILD_PIDS=`ps -ef | grep 'php' | grep -v grep |awk '{print $2}'`
echo "$CHILD_PIDS" > "$CHILD_PIDS_FILE"
The script basically deletes the main process pid and the sock file. Then writes the pids of the child processes to the file so than they can be killed once a new php5-fpm process is created.
The post-start script is
#!/bin/bash
CHILD_PIDS_FILE="/var/run/php5-fpm-child.pid"
while read PID; do
kill -9 $PID
done < $CHILD_PIDS_FILE
>$CHILD_PIDS_FILE
The post-start script deletes all the child-pids that were running before php5-fpm restarted.
Related
I am using nginx, and not apache. Just upgraded from 18.04 to 20.04 and thus php7.2 to php7.4.
However php7.4-fpm fails to start. This is my log.
ian#thebeb:/etc/php/7.4/fpm$ sudo /etc/init.d/php7.4-fpm restart
Restarting php7.4-fpm (via systemctl): php7.4-fpm.serviceJob for php7.4-fpm.service failed because the control process exited with error code.
See "systemctl status php7.4-fpm.service" and "journalctl -xe" for details.
failed!
ian#thebeb:/etc/php/7.4/fpm$ systemctl status php7.4-fpm.service
● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-01-17 21:01:20 GMT; 9s ago
Docs: man:php-fpm7.4(8)
Process: 63191 ExecStart=/usr/sbin/php-fpm7.4 --nodaemonize --fpm-config /etc/php/7.4/fpm/php-fpm.conf (code=exited, status=127)
Process: 63205 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, status=0/SUCCESS)
Main PID: 63191 (code=exited, status=127)
Jan 17 21:01:20 thebeb systemd[1]: Starting The PHP 7.4 FastCGI Process Manager...
Jan 17 21:01:20 thebeb php-fpm7.4[63191]: /usr/sbin/php-fpm7.4: symbol lookup error: /usr/sbin/php-fpm7.4: undefined symbol: pcre2_set_depth_limit_8
Jan 17 21:01:20 thebeb systemd[1]: php7.4-fpm.service: Main process exited, code=exited, status=127/n/a
Jan 17 21:01:20 thebeb systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
Jan 17 21:01:20 thebeb systemd[1]: Failed to start The PHP 7.4 FastCGI Process Manager.
ian#thebeb:/etc/php/7.4/fpm$ journalctl -xe
-- A start job for unit UNIT has begun execution.
--
-- The job identifier is 431.
Jan 17 21:01:10 thebeb dbus-daemon[3745]: [session uid=1000 pid=3745] Activating via systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested by ':1.2' (uid=1000 pid=3742 >
Jan 17 21:01:10 thebeb dbus-daemon[3745]: [session uid=1000 pid=3745] Successfully activated service 'org.freedesktop.Tracker1'
Jan 17 21:01:10 thebeb systemd[3723]: Started Tracker metadata database store and lookup manager.
-- Subject: A start job for unit UNIT has finished successfully
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit UNIT has finished successfully.
--
-- The job identifier is 431.
Jan 17 21:01:15 thebeb kernel: [UFW BLOCK] IN=enp0s3 OUT= MAC=01:00:5e:00:00:01:bc:14:01:0f:f6:e6:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
Jan 17 21:01:20 thebeb sudo[63180]: ian : TTY=pts/1 ; PWD=/etc/php/7.4/fpm ; USER=root ; COMMAND=/etc/init.d/php7.4-fpm restart
Jan 17 21:01:20 thebeb sudo[63180]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 17 21:01:20 thebeb systemd[1]: Starting The PHP 7.4 FastCGI Process Manager...
-- Subject: A start job for unit php7.4-fpm.service has begun execution
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit php7.4-fpm.service has begun execution.
--
-- The job identifier is 3745.
Jan 17 21:01:20 thebeb php-fpm7.4[63191]: /usr/sbin/php-fpm7.4: symbol lookup error: /usr/sbin/php-fpm7.4: undefined symbol: pcre2_set_depth_limit_8
Jan 17 21:01:20 thebeb systemd[1]: php7.4-fpm.service: Main process exited, code=exited, status=127/n/a
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- An ExecStart= process belonging to unit php7.4-fpm.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 127.
Jan 17 21:01:20 thebeb systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit php7.4-fpm.service has entered the 'failed' state with result 'exit-code'.
Jan 17 21:01:20 thebeb systemd[1]: Failed to start The PHP 7.4 FastCGI Process Manager.
-- Subject: A start job for unit php7.4-fpm.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit php7.4-fpm.service has finished with a failure.
--
-- The job identifier is 3745 and the job result is failed.
Jan 17 21:01:20 thebeb sudo[63180]: pam_unix(sudo:session): session closed for user root
Jan 17 21:01:41 thebeb tracker-store[63047]: OK
Jan 17 21:01:41 thebeb systemd[3723]: tracker-store.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit UNIT has successfully entered the 'dead' state.
ian#thebeb:/etc/php/7.4/fpm$
The symbol lookup error, was symbol lookup error: /usr/sbin/php-fpm7.4: undefined symbol: pcre2_set_depth_limit_8.
I have checked everything I can think of, and can't spot the problem. Now I am out of my depth! Help.
Added after request:
ian#thebeb:/etc/php/7.4/fpm$ ldd $(which php-fpm7.4)
linux-vdso.so.1 (0x00007ffefb4e7000)
libargon2.so.1 => /usr/lib/x86_64-linux-gnu/libargon2.so.1 (0x00007f13e38a6000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f13e388a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f13e373b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f13e3735000)
libapparmor.so.1 => /usr/lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f13e3720000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f13e3671000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f13e34b5000)
libssl.so.1.1 => /usr/local/lib/libssl.so.1.1 (0x00007f13e3422000)
libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 (0x00007f13e2f57000)
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x00007f13e2d0c000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x00007f13e2af0000)
libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23 (0x00007f13e2a98000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f13e28a4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f13e2881000)
/lib64/ld-linux-x86-64.so.2 (0x00007f13e3d6f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f13e2876000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f13e284d000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f13e282c000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f13e270e000)
libicuuc.so.66 => /usr/lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007f13e2526000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f13e2503000)
libicudata.so.66 => /usr/lib/x86_64-linux-gnu/libicudata.so.66 (0x00007f13e0a42000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f13e0861000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f13e0846000)
ian#thebeb:/etc/php/7.4/fpm$
pcre2_set_depth_limit_8 is a library symbol reference (on my system it is in /usr/lib/apache2/modules/libphp8.0.so) that appears, again on my system, to reside in /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.10.0.
So, I suspect that the PCRE package on your system is damaged. Check the status of your libpcre2-8-0 package.
Or just do
ldd /usr/sbin/php-fpm7.4 | grep pcre2
and check where it points, or if it says that the library was not found (in the latter case you just need to apt-get install it, and apparently the dependency check system for that library is broken, since it didn't spot the lack).
If it does point to a .so file, then let's check said file: for example (I have only a Raspberry available)
nm -gD /usr/lib/arm-linux-gnueabihf/libpcre2-8.so.0.7.1
should report all the symbols in the library, and grep'ping for ours does find it:
0000f508 T pcre2_set_depth_limit_8
If it did not, then that would mean that the library does not contain the symbol -- which to me indicates that the library has to be somehow damaged, since on other systems that symbol is there.
Ubuntu 20.04
I remembered I had a 20.04 available somewhere else. The library there is libpcre2-8.so.0.9.0:
-rw-r--r-- 1 root root 584392 Dec 7 2019 /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0
and the symbol is there. The Ubuntu package I have is libpcre2-8-0:amd64.
# nm -gD /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0 | grep pcre2_set_depth_limit_8
00000000000116f0 T pcre2_set_depth_limit_8
I just tried to update the PHP Version of the nginx server and I get this message, when I enter systemctl status php7.4-fpm.service
php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2020-12-14 20:11:31 UTC; 4min 50s ago
Docs: man:php-fpm7.4(8)
Process: 9196 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, status=0/SUCCESS)
Process: 9178 ExecStart=/usr/sbin/php-fpm7.4 --nodaemonize --fpm-config /etc/php/7.4/fpm/php-fpm.conf (code=exited, status=78)
Main PID: 9178 (code=exited, status=78)
Dec 14 20:11:31 vultr.guest systemd[1]: Starting The PHP 7.4 FastCGI Process Manager...
Dec 14 20:11:31 vultr.guest php-fpm7.4[9178]: [14-Dec-2020 20:11:31] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
Dec 14 20:11:31 vultr.guest php-fpm7.4[9178]: [14-Dec-2020 20:11:31] ERROR: FPM initialization failed
Dec 14 20:11:31 vultr.guest systemd[1]: php7.4-fpm.service: Main process exited, code=exited, status=78/n/a
Dec 14 20:11:31 vultr.guest systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
Dec 14 20:11:31 vultr.guest systemd[1]: Failed to start The PHP 7.4 FastCGI Process Manager.
Also if I check for the Version with php -v I get back the Version 7.4.13
However, if upload a test.php File with just <?php phpinfo();?> in it, the Server tells me that I still run on PHP Version 7.3.22-1+ubuntu18.04.1+deb.sury.org+1
Already tried to change the standard PHP version with sudo update-alternatives --set php /usr/bin/php7.4
Thanks for your help
I followed this tutorial (http://richardhawthorn.com/?p=82) to configure ssl on my beanstalk instances.
So my config file contains the following. It works great on 64bit ubuntu 2014.02 PHP 5.5 but on 64bit ubuntu 2014.03 v1.0.2 PHP 5.5 it does not work I get the following errors, what could be the problem?
packages:
yum:
mod24_ssl : []
Resources:
mySecurityGroup:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupName: {Ref : AWSEBSecurityGroup}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
/etc/httpd/conf.d/ssl.conf:
mode: 000777
owner: ec2-user
group: ec2-user
content: |
LoadModule ssl_module modules/mod_ssl.so
Listen 443
Order deny,allow
Allow from all
SSLEngine on
SSLCertificateChainFile "/tmp/gd_bundle.crt"
SSLCertificateFile "/tmp/server.crt"
SSLCertificateKeyFile "/tmp/server.key"
ProxyPass / http://localhost:80/ retry=0
ProxyPassReverse / http://localhost:80/
ProxyPreserveHost on
LogFormat "%h (%{X-Forwarded-For}i) %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
TransferLog /var/log/httpd/elasticbeanstalk-access_log
Jun 4 06:12:16 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:17 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:18 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:18 ip-10-253-103-13 init: httpd main process ended, respawning
Jun 4 06:12:18 ip-10-253-103-13 init: httpd respawning too fast, stopped
-------------------------------------
/var/log/httpd/error_log
-------------------------------------
[Wed Jun 04 06:12:18.328490 2014] [suexec:notice] [pid 25739] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
AH00016: Configuration Failed
My first guess (not sure though) is this issue: https://forums.aws.amazon.com/thread.jspa?messageID=545736
Also discussed here:
https://forums.aws.amazon.com/message.jspa?messageID=546965
Can you try downgrading the version of curl using an ebextension and see if it fixes your problem?
I'm trying to install php-fpm for the first time on Ubunutu. I have installed it via
sudo apt-get install php5-fpm
When the install finishes, I run ps -waux | grep php5 to see if anything is running. I get the following:
root 9625 0.5 0.6 133612 12836 ? Ss 22:49 0:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
It looks like it is running, so I tried to stop it by executing:
sudo /etc/init.d/php5-fpm stop
This appears to do nothing. No error message is given on the command line and when I run ps again, the same process exists. I am able to get it to stop if I run:
sudo service php5-fpm stop
The first time I ran this command I got an error about not being able to find a directory, but the process did stop. When I start and stop the service again, it seems to work fine and I don't get an error message about a missing directory.
Can someone explain to me why the /etc/init.d/php5-fpm method does not work? All of the tutorials I've seen use this method to start and stop php5-fpm.
Quick answer...you don't use the init.d scripts to control (stop / start /status etc) of php-fpm because it's controlled by the newer 'upstart'. Use the following service command to stop and restart etc. I think it's a bit of a 'bug' that it quietly exits without stating that it's now controlled by upstart.
More detailed look at this problem, that leads to above explanation.
I see exactly the same problem on Ubuntu 14.04, you can stop / start / get status of php5-fpm using the service commands: I.E these work fine :-
# sudo service php5-fpm status
php5-fpm start/running, process 18793
# sudo service php5-fpm stop
php5-fpm stop/waiting
# sudo service php5-fpm status
php5-fpm stop/waiting
# sudo service php5-fpm start
php5-fpm start/running, process 18949
# sudo service php5-fpm status
php5-fpm start/running, process 18949
BUT the /etc/init.d/php5-fpm command has no effect :-
# /etc/init.d/php5-fpm stop
# ps -ef | grep php
root 18949 1 0 12:15 ? 00:00:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
www-data 18952 18949 0 12:15 ? 00:00:00 php-fpm: pool www
www-data 18953 18949 0 12:15 ? 00:00:00 php-fpm: pool www
root 18970 10051 0 12:17 pts/2 00:00:00 grep --color=auto php
Note nothing is returned, and the process is not stopped. Similarly for status and start versions, nothing is returned and the process is unaffected.
I found the line that it exits the init.d script on.... init_is_upstart:
# Don't run if we are running upstart
if init_is_upstart; then
exit 1
fi
Surely it should state an error message here...like 'Use service commands to stop/start php-fpm'.
I had similar problem that relates to php5-fpm on Ubuntu 14.10.
I have configured php5-fpm for one of the virtual hosts and when trying to browse the site i got the 503 Service Unavailable.
Every time I tried
root#testupgrade:~# service php5-fpm restart
stop: Unknown instance:
php5-fpm start/running, process 2775
I got in the syslog the following:
Dec 7 14:08:53 testupgrade kernel: [ 230.711612] init: php5-fpm main process (2775) terminated with status 78
Dec 7 14:08:53 testupgrade kernel: [ 230.711639] init: php5-fpm main process ended, respawning
Dec 7 14:08:53 testupgrade kernel: [ 230.866617] init: php5-fpm main process (2783) terminated with status 78
Dec 7 14:08:53 testupgrade kernel: [ 230.866643] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.027522] init: php5-fpm main process (2791) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.027548] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.137792] init: php5-fpm main process (2799) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.137807] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.221146] init: php5-fpm main process (2807) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.221161] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.301859] init: php5-fpm main process (2815) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.301874] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.381635] init: php5-fpm main process (2823) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.381649] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.469211] init: php5-fpm main process (2831) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.469225] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.548950] init: php5-fpm main process (2839) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.548964] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.628781] init: php5-fpm main process (2847) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.628795] init: php5-fpm main process ended, respawning
Dec 7 14:08:54 testupgrade kernel: [ 231.711933] init: php5-fpm main process (2855) terminated with status 78
Dec 7 14:08:54 testupgrade kernel: [ 231.711947] init: php5-fpm respawning too fast, stopped
What I tried then is to check if my php5-fpm configuration for this virtual host pool is actually working.
It was configured to listed on a TCP port with the following configuration in /etc/php5/fpm/pool.d/www.conf
I have correctly instructed the pool to listed as follows:
listen = 127.0.0.1:9000
I tried restarting few more times with the service command and since it did not work I decided checking the startup scripts.
I edited the /etc/init/php5-fpm.conf and I noticed that I already have the latest bug-fixed version of the line "reload signal USR2".
Then I noticed the following line:
pre-start exec /usr/lib/php5/php5-fpm-checkconf
I checked the /usr/lib/php5/php5-fpm-checkconf script and noticed the syntax check that is appended to the $errors variable:
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
I executed it in the shell and noticed the following:
root#testupgrade:~# /usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
[07-Dec-2014 13:46:14] ERROR: [pool www] 'slowlog' must be specified for use with 'request_slowlog_timeout'
[07-Dec-2014 13:46:14] ERROR: failed to post process the configuration
[07-Dec-2014 13:46:14] ERROR: FPM initialization failed
This means that I have touched my php-fpm.conf and messed it up however the error was nowhere to be found and I had no indication that this is the reason for the php5-fpm service to fail starting.
I fixed the syntax in the /etc/php5/fpm/pool.d/www.conf file and then tried restarting again with the service command.
The service started and opened a tcp listener on the required port 9000.
The vhost also started working.
So always check the php-fpm syntax and configuration with the above command to avoid issues with the service not starting.
Typically an init script will not always spit out the problem causing the situation to happen. Your best option is to cat /etc/init.d/php5-fpm and find the command it is trying to run and then use that command to start the process manually.
Speaking from experience with FPM start-up scripts, FPM will normally spit out the error you cannot see or are missing from random log files and then you'll be able to find and fix that error. Once resolved, your init script should be good to go afterwards.
I have a Vagrant guest I'm using to run a Symfony 2 application locally for development. In general this is working fine, however, I am regularly finding the processes lock in the 'D+' state (waiting for I/O).
eg. I try to run my unit tests:
./bin/phpunit -c app
The task launches, but then never exits. In the process list I see:
vagrant 3279 0.5 4.9 378440 101132 pts/0 D+ 02:43 0:03 php ./bin/phpunit -c app
The task is unkillable. I need to power cycle the Vagrant guest to get it back again. This seems to happen mostly with PHP command line apps (but it's also the main command line tasks I do, so it might not be relevant).
The syslog reports a hung task:
Aug 20 03:04:40 precise64 kernel: [ 6240.210396] INFO: task php:3279 blocked for more than 120 seconds.
Aug 20 03:04:40 precise64 kernel: [ 6240.211920] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 20 03:04:40 precise64 kernel: [ 6240.212843] php D 0000000000000000 0 3279 3091 0x00000004
Aug 20 03:04:40 precise64 kernel: [ 6240.212846] ffff88007aa13c98 0000000000000082 ffff88007aa13c38 ffffffff810830df
Aug 20 03:04:40 precise64 kernel: [ 6240.212849] ffff88007aa13fd8 ffff88007aa13fd8 ffff88007aa13fd8 0000000000013780
Aug 20 03:04:40 precise64 kernel: [ 6240.212851] ffff88007aa9c4d0 ffff880079e596f0 ffff88007aa13c78 ffff88007fc14040
Aug 20 03:04:40 precise64 kernel: [ 6240.212853] Call Trace:
Aug 20 03:04:40 precise64 kernel: [ 6240.212859] [<ffffffff810830df>] ? queue_work+0x1f/0x30
Aug 20 03:04:40 precise64 kernel: [ 6240.212863] [<ffffffff811170e0>] ? __lock_page+0x70/0x70
Aug 20 03:04:40 precise64 kernel: [ 6240.212866] [<ffffffff8165a55f>] schedule+0x3f/0x60
Aug 20 03:04:40 precise64 kernel: [ 6240.212867] [<ffffffff8165a60f>] io_schedule+0x8f/0xd0
Aug 20 03:04:40 precise64 kernel: [ 6240.212869] [<ffffffff811170ee>] sleep_on_page+0xe/0x20
Aug 20 03:04:40 precise64 kernel: [ 6240.212871] [<ffffffff8165ae2f>] __wait_on_bit+0x5f/0x90
Aug 20 03:04:40 precise64 kernel: [ 6240.212873] [<ffffffff81117258>] wait_on_page_bit+0x78/0x80
Aug 20 03:04:40 precise64 kernel: [ 6240.212875] [<ffffffff8108af00>] ? autoremove_wake_function+0x40/0x40
Aug 20 03:04:40 precise64 kernel: [ 6240.212877] [<ffffffff8111736c>] filemap_fdatawait_range+0x10c/0x1a0
Aug 20 03:04:40 precise64 kernel: [ 6240.212882] [<ffffffff81122a01>] ? do_writepages+0x21/0x40
Aug 20 03:04:40 precise64 kernel: [ 6240.212884] [<ffffffff81118da8>] filemap_write_and_wait_range+0x68/0x80
Aug 20 03:04:40 precise64 kernel: [ 6240.212892] [<ffffffffa01269fe>] nfs_file_fsync+0x5e/0x130 [nfs]
Aug 20 03:04:40 precise64 kernel: [ 6240.212896] [<ffffffff811a632b>] vfs_fsync+0x2b/0x40
Aug 20 03:04:40 precise64 kernel: [ 6240.212900] [<ffffffffa01272c3>] nfs_file_flush+0x53/0x80 [nfs]
Aug 20 03:04:40 precise64 kernel: [ 6240.212903] [<ffffffff81175d6f>] filp_close+0x3f/0x90
Aug 20 03:04:40 precise64 kernel: [ 6240.212905] [<ffffffff81175e72>] sys_close+0xb2/0x120
Aug 20 03:04:40 precise64 kernel: [ 6240.212907] [<ffffffff81664a82>] system_call_fastpath+0x16/0x1b`
To provision the box, I'm sharing a local folder using:
config.vm.synced_folder "/my/local/path.dev", "/var/www", :nfs => true
Vagrant creates the following /etc/exports file on the OSX host:
# VAGRANT-BEGIN: c7d0c56a-a126-46f5-a293-605bf554bc9a
"/Users/djdrey-local/Sites/oddswop.dev" 192.168.33.101 -mapall=501:20
# VAGRANT-END: c7d0c56a-a126-46f5-a293-605bf554bc9a
Output of nfsstat on the vagrant guest
Server rpc stats:
calls badcalls badclnt badauth xdrcall
0 0 0 0 0
Client rpc stats:
calls retrans authrefrsh
87751 0 87751
Client nfs v3:
null getattr setattr lookup access readlink
0 0% 35018 39% 1110 1% 8756 9% 19086 21% 0 0%
read write create mkdir symlink mknod
5100 5% 7059 8% 4603 5% 192 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
4962 5% 262 0% 313 0% 0 0% 0 0% 1056 1%
fsstat fsinfo pathconf commit
1 0% 2 0% 1 0% 229 0%
I've ensured the Guest Additions are up to date on the guest using the plugin: vagrant-vbguest
I'm not sure how to go about debugging this. It's pretty clear to me this is a NFS issue between the guest and the Mac OSX host. If I try and up the debug logging for NFS on OSX using NFS Manager, I get a kernel panic in OSX.
Has anyone else had a similar issue? Any suggestions on a way forward would be appreciated - as power cycling the guest several times per day is unworkable.
Environment
OSX 10.8.4
Vagrant 1.2.7
Virtualbox 4.2.16
Vagrant guest O/S: Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-23-generic x86_64) [precise64.box]
I had a similar problem when running npm install within a shared nfs folder and subsequently found that disabling nfs_udp fixed the hanging issues :
config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_udp: false
You don't give enough detail on the specific configuration (e.g., the exports file, the fstab file, firewall config, etc.) for a specific answer. Here are some ideas though:
In the fstab try adding the "hard,intr" flags to the mount options -- this makes it possible to kill processes waiting for I/O on a dead mount.
Also make sure your firewall is open for rpc calls and the rpc-statd service is running.
Also figure out what version of nfs you're running and that you have the correct TCP/UDP ports open. If NFS v4 isn't working out, maybe try NFS v3.
Finally, are you connecting via IP address or hostname? Hostname is great, but make sure it always resolves correctly -- maybe in your /etc/hosts file. Alternatively, hard-code the IP addresses so there is no chance of name resolution failing...