I have a Magento 1.9 shop on a Ubuntu server - it has run without any problems for about a year. When I now open /cron.php in my Chrome browser, I get the following error: ERR_EMPTY_RESPONSE
I have looked into my apache errors log. It says:
[core:notice] [pid 1992] AH00051: child pid 2083 exit signal
Segmentation fault (11), possible coredump in /etc/apache2
... everytime when I try to load the cron.php script.
My syslog shows the following error:
kernel: [ 774.131560] php[2406]: segfault at 7ffc036eceb8 ip
00007f7c1fd7a55a sp 00007ffc036eceb0 error 6 in
libpcre.so.3.13.1[7f7c1fd67000+3d000]
I've found out, that the error occurs at a recursive function in my php script. The function looks quite ok to me.
It turned out that the PHP script had a recurive function with an infinite loop under certain conditions. I would have thought this would just lead to a script timeout. Maybe someone can explain in detail...
I'm currently experimenting with a PHP plugin called Mosquitto PHP (https://github.com/mgdm/Mosquitto-PHP/). I've got it all installed right, and under 'php -m' it seems to show up properly.
I'm using a small test code to see if it in it's basic form works:
<?php
$c = new Mosquitto\Client;
$c->onConnect(function() use ($c) {
$c->publish('mgdm/test', 'Hello', 2);
});
$c->connect('test.mosquitto.org');
for ($i = 0; $i < 100; $i++) {
// Loop around to permit the library to do its work
$c->loop(1);
}
echo "Finished\n";
?>
And that seemed to return "Finished" in my browser. So, I decided to up my game, and add a TLS connection, as documented, to this:
<?php
$c = new Mosquitto\Client;
$c->onConnect(function() use ($c) {
$c->publish('mgdm/test', 'Hello', 2);
});
$c->setTlsCertificates('mosquitto.org.crt');
$c->connect('test.mosquitto.org', '8883');
for ($i = 0; $i < 100; $i++) {
$c->loop(1);
}
echo "Finished\n";
?>
I got the certificate and I've made sure apache2 could read it and set the ownership subsequently to apache2. This turned out to give me the 500 internal sever error in my browser.
-rwsrwsrwt 1 www-data www-data 279 Jun 5 04:12 test.php
-rwxrwxrwx 1 www-data www-data 1078 Jun 30 2012 mosquitto.org.crt
Out of curiousity, I navigated to the script in shell and ran it with:
sudo php test.php
This resulting in a printed "Finished" in my ssh, and it sent the message through the broker.
This made me think it's an odd sort of permission error. Investigating further, I found these in my logs:
My apache2 log:
mod_fcgid: process /var/www/php-fcgi-scripts/web1/.php-fcgi-starter(20614) exit(communication error), get unexpected signal 11
mog_fcgid installed is:
libapache2-mod-fcgid 1:2.3.9-1+b1 amd64 FastCGI interface module for Apache 2
and it is, same with suexec is enabled as far as I can tell.:
Module fcgid already enabled
Module suexec already enabled
In a small twist of events, I changed the .php to .fcgi and gave it +x permission, and now the messages goes through the broker, but still it gives a 500 error in my browser.
suexec log shows:
[2016-06-07 14:05:58]: uid: (5004/web1) gid: (5005/client0) cmd: test.fcgi
and in my ispconfig log it shows:
[Tue Jun 07 14:08:25.567945 2016] [fcgid:warn] [pid 27861] (104)Connection reset by peer: [client 93.135.88.60:49328] mod_fcgid: error reading data from FastCGI server
[Tue Jun 07 14:08:25.568016 2016] [core:error] [pid 27861] [client 93.135.88.60:49328] End of script output before headers: test.fcgi
I'm totally lost for words here.. I need help!!
Try to increase the memory for php-fcgi (by default for cli memory_limit=-1).
I think this case should resolve your problem.
UPDATE
I have installed mosquitto (from php7 branch) and try it (run test.php from repository examples. php 7.0.7). And i have segfault to
segfault at 8 ip 00005574a41c753f sp 00007ffc2dc85da0 error 6 in php7.0[5574a3f80000+391000]
It seems that this is extension bug.
You can try to debug this segfault (https://bugs.php.net/bugs-generating-backtrace.php) and send report to extension developers.
I just tried to install the PHP SDK on my Ubuntu 14.04.
I started with the C SDK, then isntalled the PHP SDK with pecl.
Everything works fine, i got no errors, a couchbase.so is installed in /usr/lib/php55/…
But when i add a
extension=couchbase.so to my php.ini everything broke, i can't display any php page.
I checked the logs and see:
[Wed Jan 20 11:36:39.872396 2016] [core:notice] [pid 4265] AH00052: child pid 4298 exit signal Segmentation fault (11)
Looks bad uh ?
Any tips to make this works?
I mentioned this to the project maintainer this morning and his hypothesis is that PHP may have had a change in 5.5 that has lead to the breakage as he's seen this sort of thing in the past. Perhaps you can try an older version or get more info per the comment on backtraces above.
Our application runs in a Docker container on AWS:
Operating system: Ubuntu 14.04.2 LTS (Trusty Tahr)
Nginx version: nginx/1.4.6 (Ubuntu)
Memcached version: memcached 1.4.14
PHP version: PHP 5.5.9-1ubuntu4.11 (cli) (built: Jul 2 2015 15:23:08)
System Memory: 7.5 GB
We get blank pages and a 404 Error less frequently. While checking the logs, I found that the php-child process is killed and it seems that memory is mostly used by memcache and php-fpm process and very low free memory.
memcache is configured to use 2 GB memory.
Here is php www.conf
pm = dynamic
pm.max_children = 30
pm.start_servers = 9
pm.min_spare_servers = 4
pm.max_spare_servers = 14
rlimit_files = 131072
rlimit_core = unlimited
Error logs
/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] WARNING: [pool www] child 259 exited on signal 11 (SIGSEGV - core dumped) after 1339.412219 seconds from start
/var/log/nginx/error.log
2015/07/29 14:37:09 [error] 141#0: *2810 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: x.x.x.x, server: _, request: "GET /suggestions/business?q=Selectfrom HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "example.com", referrer: "http://example.com/"
/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] NOTICE: [pool www] child 375 started
/var/log/nginx/php5-fpm.log:[29-Jul-2015 14:37:56] WARNING: [pool www] child 290 exited on signal 11 (SIGSEGV - core dumped) after 1078.606356 seconds from start
Coredump
Core was generated by php-fpm: pool www.Program terminated with signal SIGSEGV, Segmentation fault.#0 0x00007f41ccaea13a in memcached_io_readline(memcached_server_st*, char*, unsigned long, unsigned long&) () from /usr/lib/x86_64-linux-gnu/libmemcached.so.10
dmesg
[Wed Jul 29 14:26:15 2015] php5-fpm[12193]: segfault at 7f41c9e8e2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:28:26 2015] php5-fpm[12211]: segfault at 7f41c966b2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:29:16 2015] php5-fpm[12371]: segfault at 7f41c9e972da ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:36 2015] php5-fpm[12469]: segfault at 7f41c96961e9 ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:43 2015] php5-fpm[12142]: segfault at 7f41c9e6c2bd ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:07 2015] php5-fpm[11917]: segfault at 7f41c9dd22bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:54 2015] php5-fpm[12083]: segfault at 7f41c9db72bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
While googling for this same issue, and trying hard to find a solution that was not related to sessions (because I have ruled that out) nor to bad PHP code (because I have several websites running precisely the same version of WordPress, and none have issues... except for one), I came upon an answer telling that a possible solution did involve removing some buggy extension (usually memcache/d, but could be something else).
Since I had this same site working flawlessly on one Ubuntu server, when switching to a newer server, I immediately suspected that it was the migration from PHP 5.5 to 7 that caused the problem. It was just strange because no other website was affected. Then I remembered that another thing was different on this new server: I had also installed New Relic. This is both an extension and a small server that runs in the background and sends a lot of analytics data to New Relic for processing. Allegedly, it's a PHP 5 extension, but, surprisingly, it loads well on PHP 7, too.
Now here comes the tricky bit. At some point, I had installed W3 Total Cache for the WordPress installation of that particular website. Subsequently, I saw that the performance of that server was so stellar that W3TC was unnecessary, and simply stuck to a much simpler configuration. So I could uninstall W3TC. That's all very nice, but... I forgot that I had turned New Relic on W3TC, too (allegedly, it adds some extra analytics data to be sent to New Relic). When uninstalling W3TC, probably there was 'something' left on the New Relic configuration in my server which was still attempting to send data through the W3TC interface (assuming that W3TC has an interface... I really have no idea how it works at that level), and, because that specific bit of code was missing, the php_fpm handler for that website would fail... some of the time. Not all the time, because I'm assuming that, in most cases, nginx was sending static pages back. Or maybe php_fpm, set to 'recycle' after 100 calls or so, would crash-on-stop. Whatever exactly was happening, it was definitely related to New Relic — as soon as I removed the New Relic extension from PHP, that website went back to working normally.
Because this is such a specific scenario, I'm just writing this as an answer, in the remote chance that someone in the future googles for the exact problem.
In my case it was related to zend debug/xdebug. It forwards some TCP packets to the IDE (PhpStorm), that was not listening on this port (debugging was off). The solution is to either disable these extensions or enable debug listening on the debugging port.
I had this problem after installing xdebug, adding some properties to /etc/php/7.1/fpm/php.ini and restarting nginx. This is running on a Homestead Laravel box.
Simply restarting the php7.1-fpm service solved it for me.
It can happen if PHP is unable to write the session information to a file. By default it is /var/lib/php/session. You can change it by using configuration session_save_path.
phpMyAdmin having problems on nginx and php-fpm on RHEL 6
In my case it was Xdebug. After uninstalling it, it got back to normal.
In my case, it was caused by the New Relic PHP Agent. Therefore, for a specific function that caused a crash, I added this code to disable New Relic:
if (function_exists('newrelic_ignore_transaction')) {
newrelic_ignore_transaction();
}
Refer to: https://discuss.newrelic.com/t/how-to-disable-a-specific-transaction-in-php-agent/42384/2
In our case it was caused by Guzzle + New Relic. In the New Relic Agent changelog they've mentioned that in version 7.3 there was some Guzzle fix, but even using the 8.0 didn't work, so there is still something wrong. In our case this was happening only in two of our scripts that were using Guzzle. We found that there are two solutions:
Set newrelic.guzzle.enabled = false in newrelic.ini. You will lose data in the External Services tab this way, but you might not need it anyway.
Downgrade New Relic Agent to version 6.x that somehow also works
If you are reading this when they've released something newer than version 8.0, you could also try to update New Relic Agent to the latest and maybe they fixed that
In my case I had deactivated the buffering function ob_start("buffer"); in my code ;)
A possible problem is PHP 7.3 + Xdebug. Please change Xdebug 2.7.0beta1 to Xdebug 2.7.0rc1 or the latest version of Xdebug.
For some reason, when I remove profile from my xdebug.ini modes, it fixes it for me.
i.e. change
xdebug.mode=debug,develop,profile
to
xdebug.mode=debug,develop
When performing a specific action* in a Drupal 7 project, I get the following error in /var/log/apache2/error.log:
[Fri Jun 26 09:53:55.307644 2015] [core:notice] [pid 1553] AH00051: child pid 9998 exit signal Segmentation fault (11), possible coredump in /etc/apache2
Except that when using the step by step function of Xdebug, it doesn't crash.
And when using xdebug.auto_trace=ON, it doesn't crash either.
What could cause a segmentation fault in PHP, except when using Xdebug?
*: The error occurs when sending an email, but only when the recipient is the currently logged in user.
By putting log messages in the code, I've been able to determine that the crash occurs when autoloading the MailMIME class.
In includes/bootstrap.inc, in the _registry_check_code function, if I put the following code:
if($type == 'class' && $name == 'MailMIME')
{
file_put_contents('/tmp/log.txt', "DEBUG 01\n", FILE_APPEND);
}
before line 3147, which is:
$file = Database::getConnection('default', 'default')->query("SELECT filename FROM {registry} WHERE name = :name AND type = :type", array(
':name' => $name,
':type' => $type,
))
->fetchField();
then, I can see "DEBUG 01" in my log file, and it crashes.
However, if I put the same code after the lines 3147 to 3151, it stops crashing...
EDIT: I am able to reproduce the bug on my Ubuntu 14.04 machine with PHP 5.5, but I can't reproduce it on a Windows machine with PHP 5.6.