Ошибка PHP и apache22 core dumped Дневник Максим Боголепов
Такое у меня уже происходило однажды, поэтому рецепт “лечения” был уже известен. Такая ошибка возникала ранее из-за неправильного загружаемого extension языка php5 (в составе порта lang/php5-extensions). Проверить, что это так и есть, можно простыми командами:
# php -v Ошибка сегментации: 11 (core dumped) # dmesg pid 6066 (php), uid 0: exited on signal 11 (core dumped)
А в корне / находилось уже два core dump, от apache22 и php5:
# ls -Al / | grep core -rw------- 1 root wheel 44834816 17 дек 9:22 httpd.core -rw------- 1 root wheel 9732096 17 дек 9:26 php.core
Чтобы выяснить, какой из extensions вызывает данную ошибку, необходимо в файле по пути /usr/local/etc/php/extensions.ini закомментировать все вызываемые extensions с помощью ; и затем поочередно раскомментировать их по одному, проверяя после каждой операции командой php -v . Выполняя данный цикл команд удалось выяснить, что проблема была в расширении recode.so.
# nano -w /usr/local/etc/php/extensions.ini . extension=iconv.so ;extension=recode.so extension=pcntl.so . # php -v PHP 5.4.9 (cli) (built: Dec 17 2012 09:37:38) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
С закомментированным ;extension=recode.so apache тоже стартовал без ошибок:
# /usr/local/etc/rc.d/apache22 start Performing sanity check on apache22 configuration: Syntax OK Starting apache22. # netstat -tan | grep LIST | grep 80 tcp4 0 0 *.80 *.* LISTEN
Rating: 4.5/5(4 votes cast)
PHP-FPM and continuos «exited on signal 11»
I’ve a Hp web server with Xeon E5504 2ghz and 8gb ram, with freebsd 8.2-p9 amd64, nginx 1.2.1, PHP 5.3.14, mysql 5.5.25, apc, memcached and other package installed using freebsd ports. (conf file at the end of that message) My trouble are simple, I’ve a lot of «exited on signal 11» in /var/log/messages and when php-fpm child die I’ve «502 gateway error» on my website, that’s really boring because I’ve a lot of that errors in a day, in that php-fpm conf I’ve forced it to an heavy configuration with a 150 of php-fpm’s child in static mode, and pm.max_requests = 10000000, but in my php-fpm log I found for each child:
[19-Jul-2012 18:58:14.666913] NOTICE: pid 84563, fpm_children_make(), line 421: [pool www] child 84717 started [19-Jul-2012 18:58:14.666984] DEBUG: pid 84563, fpm_event_loop(), line 409: event module triggered 1 events [19-Jul-2012 18:58:17.403217] DEBUG: pid 84563, fpm_event_loop(), line 409: event module triggered 2 events [19-Jul-2012 18:58:17.407442] DEBUG: pid 84563, fpm_got_signal(), line 72: received SIGCHLD [19-Jul-2012 18:58:17.407552] WARNING: pid 84563, fpm_children_bury(), line 252: [pool www] child 84563 exited on signal 11 (SIGSEGV) after 39.849444 seconds from start Jul 19 18:58:14 web1 kernel: pid 84563 (php-fpm), uid 1001: exited on signal 11 As you can see in last link, that are last rows:
#659 0x0000000801534de0 in ?? () from /lib/libc.so.7 #660 0x0000000000000001 in ?? () #661 0x00007fffffffec08 in ?? () #662 0x000000000000000f in ?? () Cannot access memory at address 0x800000000000 Jul 24 17:58:41 web1 kernel: pid 3887 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:42 web1 kernel: pid 3998 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:42 web1 kernel: pid 3895 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:42 web1 kernel: pid 3892 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:43 web1 kernel: pid 3889 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:43 web1 kernel: pid 3898 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:44 web1 kernel: pid 3886 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:44 web1 kernel: pid 3999 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:45 web1 kernel: pid 3896 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:45 web1 kernel: pid 4000 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:45 web1 kernel: pid 3893 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:55 web1 kernel: pid 3885 (php-fpm), uid 0: exited on signal 5 (core dumped) php.ini (only difference from original file)
[PHP] memory_limit = 128M apc.enabled=1 apc.shm_size=128M apc.ttl=0 apc.mmap_file_mask=/tmp/apc/apc.XXXXXX error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE display_errors = On display_startup_errors = On track_errors = On html_errors = On upload_max_filesize = 4M [Date] date.timezone = Europe/Rome [browscap] browscap = /home/serverweb/etc/php/browscap.ini php-fpm.conf (only difference from original file)
[global] error_log = /home/serverweb/log/php-fpm/error.log log_level = debug emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 10s process.max = 0 [www] user = web group = web listen = 127.0.0.1:9999 listen.allowed_clients = 127.0.0.1 pm = static pm.max_children = 16 pm.max_requests = 10000000 slowlog = /home/serverweb/log/php-fpm/$pool.log.slow php-fpm дочерний процесс завершен по сигналу 11
Наше приложение работает на контейнере докеров на AWS. Операционная система: Ubuntu 14.04.2 LTS Nginx Версия: nginx/1.4.6 (Ubuntu) Версия Memcached: memcached 1.4.14 PHP-версия: PHP 5.5.9-1ubuntu4.11 (cli) (построено: 2 июля 2015 15:23:08) Системная память: 7,5 ГБ. Мы получаем пустые страницы и 404 Ошибка реже. При проверке журналов обнаружено, что процесс php-child убит, и кажется, что память в основном используется процессом memcache и php-fpm и очень низкой свободной памятью. memcache настроен на использование памяти 2 ГБ. Вот 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 /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 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 [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] Вы используете docker-compose или запускаете напрямую с docker-machine? Если возможно, сообщите нам команды или настройки для запуска служб.
Некоторые другие пользователи сообщили о проблеме совместимости с PHP 5.5 и расширением memcache. Любое решение для устранения этой проблемы. github.com/yiisoft/yii2/issues/7100
9 ответов
В то время как поиск по этой же проблеме и попытка найти решение, не связанное с сеансами (потому что я это вынес), а также плохой PHP-код (потому что у меня есть несколько сайтов, работающих точно в той же версии WordPress, и никто не имеет проблем. кроме одного), я пришел к ответу, в котором говорилось, что возможное решение связано с удалением некоторого багги-расширения (обычно memcache/d, но может быть что-то еще).
Поскольку у меня был тот же самый сайт, работающий безупречно на одном сервере Ubuntu, при переключении на более новый сервер, я сразу же подозревал, что это вызвало проблему с PHP 5.5 до 7. Это было просто странно, потому что ни один другой сайт не пострадал. Затем я вспомнил, что на этом новом сервере было другое: я также установил New Relic. Это как расширение, так и небольшой сервер, который работает в фоновом режиме и отправляет множество аналитических данных в New Relic для обработки. Предположительно, это расширение PHP 5, но, что удивительно, он хорошо загружается и на PHP 7.
Теперь наступает сложный бит. В какой-то момент я установил W3 Total Cache для установки WordPress этого конкретного сайта. Впоследствии я увидел, что производительность этого сервера была настолько зрелищной, что W3TC не требовалась, и просто придерживалась гораздо более простой конфигурации. Поэтому я смог удалить W3TC. Это все очень приятно, но. Я забыл, что я тоже превратил новую реликвию в W3TC (предположительно, она добавляет некоторые дополнительные аналитические данные для отправки в New Relic). При удалении W3TC, вероятно, было что-то в конфигурации New Relic на моем сервере, которая все еще пыталась отправить данные через интерфейс W3TC (при условии, что W3TC имеет интерфейс. Я действительно не знаю, как это работает при этом уровень), и, поскольку этот конкретный бит кода отсутствовал, обработчик php_fpm для этого веб-сайта не срабатывает. иногда. Не все время, потому что я предполагаю, что в большинстве случаев nginx отправлял статические страницы назад. Или, может быть, php_fpm, настроенный на «переработку» после 100 вызовов или около того, будет аварийно завершен. Независимо от того, что конкретно происходило, это было определенно связано с New Relic — как только я удалил расширение New Relic из PHP, этот веб-сайт вернулся к нормальной работе.
Поскольку это такой специфический сценарий, я просто пишу это как ответ, в отдаленном случае, что кто-то в будущем поймает проблему для конкретной проблемы.
Спасибо за отличную рецензию! У меня была очень похожая ситуация, но отключение newrelic модуля не решило проблему для меня. Еще немного покопавшись, я обнаружил, что модуль Opcache может быть частой причиной конфликта. После отключения этого я больше не вижу segfaults, и New Relic снова включен. Я также недавно установил последнее расширение загрузчика ionCube для php 7, которое является еще одним расширением Zend, которое могло быть причиной конфликта, но у меня нет возможности отключить его, поэтому я не могу проверить тот.
Странно конкретно так же, как и моя проблема — обновил WP форму php5 до php7 с помощью W3TC и New Relic. Убрал PHP новую реликвию и все хорошо!
На самом деле это, скорее всего, проблема в de serializer для php-memcached. Это расширение не является действительно ошибочным, но сериализатор по умолчанию время от времени портит. Очень сложно найти других с такими же ошибками. Вы можете это исправить, установив php5-msgpack и добавив его в memcached.ini: memcached.serializer=msgpack
Забыл упомянуть, что это происходит только тогда, когда включен opcache. как утверждает Эван. Кроме того, эти 2 в вашем INI-файле также должны помочь opcache.validate_permission=0 , opcache.validate_root=0
Спасибо за этот совет. Помогло то, что эта проблема связана с расширениями php в целом. В моем случае это была проблема с отладкой.
Это может произойти, если php не сможет записать информацию о сеансе в файл По умолчанию это /var/lib/php/session Вы можете изменить его, используя конфигурацию session_save_path