I had lot of exit signal Segmentation fault (11) errors in the apache log file.
After a few hours of disabling things and doing some tests I found that this happens only when I've a HTML form with more than 85 fields doing a POST over HTTPS, I mean.. if I try to do the POST with 84 fields, it works but if I try with 86 I have an error in the browser and the segmentation fault in the log file.
I tried to disable the firewall, change PHP settings and nothing works (is not related to the maximum of post fields in the php.ini), but when I tried to do that over HTTP it works fine.
I'm doing this in a simple HTML file so I think is not an issue related to PHP.
Any ideas? Suggestion? Thanks!
Apache Version
Server version: Apache/2.4.39 (Unix)
Server built: May 10 2019 11:45:46
OS
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-1160.15.2.el7.x86_64
Architecture: x86-64
I have a very weird error with symfony. If I create a project with the default project creation command and go into the new folder to start the local webserver I get an error:
Jan 27 17:51:00 |DEBUG| PHP Reloading PHP versions
Jan 27 17:51:00 |DEBUG| PHP Using PHP version 7.4.2 (from default version in $PATH)
Jan 27 17:51:00 |DEBUG| PHP unable to find an available port error="lookup localhost on AN_INTERESTING_IP: no such host" path="/usr/bin/php" php="7.4.2"
Jan 27 17:51:00 |INFO | SERVER shut down, bye!
lookup localhost on AN_INTERESTING_IP: no such host
Yesterday I had no problems to start the local webserver.
Additionally, the interesting thing is, if I start the local webserver in an other non-symfony-directory the webserver starts without an exception.
Maybe someone has experience with this problem?
Kind regards!
I had the same problem today and for some reason the file /etc/hosts lacked an entry for localhost. So I added
127.0.0.1 localhost
After that it worked just fine.
I let my host upgrade php version to 7.2 and after that I am getting error 500 message(Internal Server Error) on my wordpress page.
I am using Virtualmin.
When opening error log I get the following:
[Mon Jan 06 16:04:41 2020] [error] (13)Permission denied: exec of '/etc/httpd/bin/suexec' failed
[Mon Jan 06 16:04:41 2020] [error] Premature end of script headers: php7.2.cgi
I searched for the solution elsewhere but didn't find any solution.
How can I solve this?
You can go to >>> virtualmin >>> serve configuration >> website options
And make the change to
FCGI, fpm or what your system is available
I can't figure out the exact solution, but the web host told me that because this server had somehow been accessed by malware, this whole thing had to be closed down and the domain moved to a new address.
Moving domain to a new server solved this problem.
This would be something to ask your Hosting Provider, Potentially they have changed the PHP Handler (Eg from suPHP to FastCGI)
you have upgraded PHP, but your Virtualmin is not configured to use it correctly.
On Virtualmin go to system settings -> Re-check configuration, Virtualmin will detect new PHP version and configure it to use on your server.
I am having some difficulty using PHP Xdebug with the PHP's internal server provided by later releases of Eclipse. I am running Eclipse for PHP Developers Version: Oxygen.3a Release (4.7.3a). Interestingly enough Xdebug is working quite well with Apache 2, but not the internal PHP server.
Note that the PHP internal server is running. I can use ‘Run As – 1Run on Server’ to run a phpinfo PHP script and a helloworld PHP script. In these cases, the PHP internal server is started with the expected operands. The Linux ps command returns:
/usr/bin/php -S 127.0.0.1:8000 -t /home/peter/eclipse-workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/htdocs
Note that port 8000 is used to start the internal PHP server (correctly as best I can tell) and no –n operand is specified. This causes the /etc/php/7.0/cli/php.ini file to be processed (correctly as best I can tell).
Note that port 80 was originally used to run this server. Of course, port 80 is restricted to root applications. The change to port 8000 was required to get the internal PHP server to start at all.
Also note that checking ‘Use system default php.ini configuration’ and clearing the PHP ini file (optional) field in the PHP Executable preferences was required to get rid of the –n operand.
Also note that I am having some difficulty switching between ‘Run As’ and ‘Debug As’. In some cases I get a message showing that the required port (8000) is already in use. However, I have not found a way to reproduce this problem so far.
Using the procedures described above, the debug internal PHP server was started without the –n operand and is processing the php.cli file. The Linux ps command returns:
/usr/bin/php -S 127.0.0.1:17278 -t /home/peter/eclipse-workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/htdocs
One question is why port 17278 was specified, rather then the expected port (8000). Running phpinfo() shows that Xdebug appears to be installed in the debug internal web server. A few settings include:
xdebug support – enabled
IDE Key – peter (my userid on this machine)
DBGp – Common DeBuGger Protocol - $Revision: 1.145 $
xdebug.remote.enable – on
xdebug.remote.port – 9000
I tried to debug helloworld.php. The console has the following two messages. The first shows a 404 code. The second shows a 200 code:
[Sun Apr 22 17:36:20 2018] 127.0.0.1:50358 [404]: /?start_debug=1&debug_fastfile=1&use_remote=1&ZRayDisable=1&send_sess_end=1
&debug_session_id=1003&debug_start_session=1&debug_port=10137 - No such file or directory
[Sun Apr 22 17:36:20 2018] 127.0.0.1:50362 [200]: /Server-docroou/helloworld.php?start_debug=1&debug_fastfile=1&use_remote=1&ZRayDisable=1&send_sess_end=1
&debug_session_id=1003&debug_start_session=1&debug_port=10137
Note that the debug port is specified as 10137. Perhaps this is causing the problem. Port 10137 is normally used by the Zend Debugger which I am not using.
Does anyone have any ideas? Thank you in advance.
Problem fixed in PDT 6.0 : https://bugs.eclipse.org/bugs/show_bug.cgi?id=533928 ;)
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