Как и ожидалось, ошибка сборщика мусора. Исправление было сделано недавно и лишь для версии PHP 5.6 alpha. В данном случае есть два пути решения:
1) Простой и относительно быстрый.
Для воспроизведения ошибки нужны довольно-таки необычные условия. Замена хотя бы одной строчки из примера выше приводит к работающему коду. Это значит, что если чуть-чуть поменять проблемный код на сайте, ошибка перестанет себя проявлять.
Для того чтобы найти проблемный код, нужно обратиться к логу Nginx. В частности, необходимо найти все ссылки, для которых Apache возвратил код 502 и попробовать пройти по этим ссылкам. Если это действие приведет к Segmentation fault, необходимо последовательно комментировать участки кода вне ядра Битрикс (см. далее), пока Segmentation fault не перестанет происходить. Как только нужный участок кода будет найдет, необходимо переписать его другим образом.
Сомнительно, что проблемный код расположен в ядре Битрикс: эта ошибка PHP присутствует во всех версиях PHP и на всех платформах. В частности, я тестировал на: 5.3.10-1 x64, Ubuntu, 5.4.9-4 x64, Ubuntu, 5.3.3-27 i686, CentOS, 5.3.3-22 x64, CentOS. Если бы проблема таилась лишь в коде Битрикс, ее давно бы уже заметили.
Плюсы такого подхода: можно решить проблему достаточно быстро.
Минусы такого подхода: настоящая проблема (ошибка в интерпретаторе PHP) не решается, потому проблема может проявить себя снова (хотя шансы и невелики).
2) Для сильных духом.
Заключается в том, чтобы разобрать rpm-пакет, сделать патч с исправлением для исходного кода PHP. Пересобрать rpm-пакет и заменить существующую версию PHP на исправленную. При этом, так как все будет сделано через rpm, возможность обновления PHP штатными средствами операционной системы не потеряются.
Плюсы такого подхода: устраняется именно причина проблемы — ошибка в интерпретаторе PHP.
Минусы такого подхода: после каждого обновления PHP патч придется делать заново, иначе проблема вернется. То есть, придется следить за обновлениями. Кроме того, выполнение всех необходимых действий займет довольно много времени: нужно будет поднимать еще одну виртуальную машину (желательно), перекомпилировать PHP, возиться с rpm и так далее.
Описание второго пути потребует довольно много времени, потому, смогу написать инструкцию только если этот подход точно будет выбран (свободного времени катастрофически не хватает, не хотелось бы его терять).
P.S. Сделал исправленный rpm-пакет для текущей версии виртуальной машины Битрикс. Но там php-5.3.3-27, для вашего случая не подойдет.
Возможно после перехода на VMBitrix 4.3 решусь и на второй
Если правильно понял второй способ, нужно сделать патч для php, пересобрать можно так А вот что поправить в исходниках php? Если можно выложите кусок кода или хотя бы примерно где искать.
Относительно первого метода, я так понял нужно анализировать error-лог ngnix. Но в нем в основном ошибки что не найден файл вида /home/bitrix/mysite/bitrix/main.post.form/templates.default/images/spoiler.png
На файл с приведенным выше скриптом ngnix записал ошибку закрытия подключения апача.
Не могу понять что как узнать что вернул апач ngnix.
Следует обратиться к access.log — URL и коды ответа от backend фиксируются там. В виртуальной машине Битрикс он может быть отключен. Чтобы его включить, в файле /etc/nginx/nginx.conf необходимо закомментировать следующую строку:
Действительно access.log был выключен, включил в конфиге.
Запустил скрипт из поста #20, получил в error.log Segmentation fault (11) и в access.log код 502. После этого дождался очередной ошибки Segmentation fault (11), но в access.log 502 кода не было, да и вообще ошибок нет.
Может что access.log момент падения апача не был записан ? Есть какой нибудь удобный анализатор логов под Windows?
1) Поиск в логе производится по коду 502, а записывается другой код (500, 503).
2) Процессы Apache периодически падают сам по себе, без запроса. Тогда это проблема, не связанная с той, что описана в комментарии #17. Мне этот вариант видится крайне маловероятным.
3) В конфигурационных файлах Nginx есть еще одна директива access_log off (или /dev/null), которая переопределяет общую (ту что в nginx.conf) для каких-то location. Что выдает команда:
Код
grep -Ri access_log /etc/nginx
Во всех остальных случаях соответствующая запись должна быть зафиксирована в логе.
Анализатор логов под Windows, боюсь, подсказать не смогу. Очень давно не работал с этой ОС.
Иван пишет: 1) Поиск в логе производится по коду 502, а записывается другой код (500, 503).
Проверил ёщё раз 5хх ошибок не генерируется
Цитата
Иван пишет: 3) В конфигурационных файлах Nginx есть еще одна директива access_log off (или /dev/null), которая переопределяет общую (ту что в nginx.conf) для каких-то location. Что выдает команда:
То есть, если обратиться к скрипту из комментария #20, то запись в access.log Nginx есть? При этом, в логе ошибок Apache существуют записи о Segmentation fault, для которых в access.log Nginx соответствий нет?
Если все так, то остаются лишь два случая:
1) Существуют ситуации, когда запросы уходят напрямую в Apache, минуя Nginx. Такие обращения может создавать система мониторинга (например, Nagios), или, если Apache и iptables настроены соответствующим образом, запросы могут приходить извне на другой порт.
2) Сомнительный вариант 2 из списка выше. Который, в свете имеющихся данных, перестает казаться таким уж сомнительным.
Что касается указанного участка конфигурационного файла Nginx — он нужен для построения графиков сервисом munin. Как видно из приведенных настроек, обращение к Apache в этом случае не происходит, потому, его можно не рассматривать. Лог access1.log пустой, так как сервис munin, вероятнее всего, отключен.