На post запросах отваливается php5-fpm
Всем привет!
Если обычно в вопросах, касаемых linux, у меня кривые руки и сам всё ломаю, то теперь я не при чём :-)
В общем, система debian 7.
Добавил dotdeb-репозитории и обновился:
Всё прошло нормально. Т.е. по сути обычный апдейт.
Но вот после этого mysql отвалился и перестал запускаться. Проблему нагуглил быстро — в my.conf добавился новый параметр, из-за которого мускул не хотел запускаться:
А дальше веселее. Сайт на фронте работает прекрасно.
В админке все страницы открываются, дерево ресурсов отображается, но как только дело доходит до сохранения чего угодно — будь то ресурс, чанк или настройка — всё, тут же ajax-запрос отваливается с 502й, все последующие запросы отдают 502, фронтенд перестаёт работать и падает по таймауту.
При чём в базу изменения успевают сохраниться, а вот дальше всё — магия.
Чтобы снова всё завести, надо перезапустить php5-fpm:
При чём что удивительно — когда открывается страница в админке, modExt делает множество ajax запросов методом post и ничего, всё работает:
А вот когда что-нибудь сохраняется, то всё, приплыли:
В логах у nginx вот это:
В логах у php5-fpm вот это:
stackoverflow.com/questions/12533072/php-fpm-for-php5-4
forum.nginx.org/read.php?25,253984
Но там всё без ответа.
В общем, как всегда, беда :-(
Помогите, кто чем может, без вас ведь не справлюсь.
p.s. На сервере лежит всего 4 сайта, практически без нагрузки, памяти достаточно. Debian 7.
Если обычно в вопросах, касаемых linux, у меня кривые руки и сам всё ломаю, то теперь я не при чём :-)
В общем, система debian 7.
Добавил dotdeb-репозитории и обновился:
sudo apt-get update
Почему-то не всё смогло скачаться (это вывод в консоли):{здесь список скачавшихся пакетов}
Err http://ppa.launchpad.net wheezy/main Sources
404 Not Found
Err http://ppa.launchpad.net wheezy/main i386 Packages
404 Not Found
{здесь список скачавшихся пакетов}
W: Failed to fetch http://ppa.launchpad.net/nginx/stable/ubuntu/dists/wheezy/main/source/Sources 404 Not Found
W: Failed to fetch http://ppa.launchpad.net/nginx/stable/ubuntu/dists/wheezy/main/binary-i386/Packages 404 Not Found
E: Some index files failed to download. They been ignored, or old ones used instead.
Ну, думаю, ладно. Проапгрейдимся:sudo apt-get upgrade
Всё прошло нормально. Т.е. по сути обычный апдейт.
Но вот после этого mysql отвалился и перестал запускаться. Проблему нагуглил быстро — в my.conf добавился новый параметр, из-за которого мускул не хотел запускаться:
explicit_defaults_for_timestamp
Закомментировал — завелось.А дальше веселее. Сайт на фронте работает прекрасно.
В админке все страницы открываются, дерево ресурсов отображается, но как только дело доходит до сохранения чего угодно — будь то ресурс, чанк или настройка — всё, тут же ajax-запрос отваливается с 502й, все последующие запросы отдают 502, фронтенд перестаёт работать и падает по таймауту.
При чём в базу изменения успевают сохраниться, а вот дальше всё — магия.
Чтобы снова всё завести, надо перезапустить php5-fpm:
sudo service php5-fpm restart
и всё снова работает до первого сохранения в админке.При чём что удивительно — когда открывается страница в админке, modExt делает множество ajax запросов методом post и ничего, всё работает:
А вот когда что-нибудь сохраняется, то всё, приплыли:
В логах у nginx вот это:
readv() failed (104: Connection reset by peer) while reading upstream and recv() failed (104: Connection reset by peer) while reading response header from upstream: "fastcgi://unix:/var/run/php5-sitename.sock"
Ошибка, в целом, гуглится. Говорят это php-сокет отваливается по таймауту. Но какой нафиг таймаут, если скрипт практически без задержек отдаёт 502, не думая. В общем, попробовав несколько вариантов предложенных гуглом решений, проблему локализовать не получилось.В логах у php5-fpm вот это:
[22-Oct-2014 11:43:35] WARNING: [pool sitename] child 21446 exited with code 127 after 372.555343 seconds from start
[22-Oct-2014 11:43:35] NOTICE: [pool sitename] child 21523 started
По этой ошибке удалось нагуглить:stackoverflow.com/questions/12533072/php-fpm-for-php5-4
forum.nginx.org/read.php?25,253984
Но там всё без ответа.
В общем, как всегда, беда :-(
Помогите, кто чем может, без вас ведь не справлюсь.
p.s. На сервере лежит всего 4 сайта, практически без нагрузки, памяти достаточно. Debian 7.
root@servname:~# mysql --version
mysql Ver 14.14 Distrib 5.5.40, for debian-linux-gnu (i686) using readline 6.2
root@servname:~# php -v
PHP 5.4.33-1~dotdeb.1 (cli) (built: Sep 19 2014 12:32:33)
Copyright © 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright © 1998-2014 Zend Technologies
root@servname:~# nginx -v
nginx version: nginx/1.2.1
Комментарии: 6
.
502 — это общая ошибка, когда nginx спросил, а php не ответил.
reset by peer — это когда php не ответил вообще. То есть, просто взял и умер, безо всяких таймаутов, или с ними — не важно. Главное, что помер.
Соответственно, искать тебе нужно, отчего php неожиданно заворачивает ласты. Для этого нужно понять, когда именно он это делает?
При сохранении ресурсов? А что там происходит, какие есть плагины на сохранение?
Повторяется ли ситуация при сохранении сниппета? А системной настройки?
Таким образом, потихоньку, сужай круг подозреваемых. Ну и, конечно, включи подробнейшие логи везде, где можно.
У меня была такая точно такая же ошибка, когда я сам в одном из скриптов перезапускал php и очень удивлялся, отчего при выполнении этого скрипта процесс всегда падает =) Понятно дело, в логах было чисто, а php reset by peer и 502 в nginx.
reset by peer — это когда php не ответил вообще. То есть, просто взял и умер, безо всяких таймаутов, или с ними — не важно. Главное, что помер.
Соответственно, искать тебе нужно, отчего php неожиданно заворачивает ласты. Для этого нужно понять, когда именно он это делает?
При сохранении ресурсов? А что там происходит, какие есть плагины на сохранение?
Повторяется ли ситуация при сохранении сниппета? А системной настройки?
Таким образом, потихоньку, сужай круг подозреваемых. Ну и, конечно, включи подробнейшие логи везде, где можно.
У меня была такая точно такая же ошибка, когда я сам в одном из скриптов перезапускал php и очень удивлялся, отчего при выполнении этого скрипта процесс всегда падает =) Понятно дело, в логах было чисто, а php reset by peer и 502 в nginx.
В общем, нашёл виновника.
Это (кто бы мог подумать) — APC.
В общем, когда меняешь настройку обработчика кэша с xPDOFileCache на cache.xPDOAPCCache (cache_prefix, разумеется, задан), то всё работает в штатном режиме до тех пор, пока существует папка core/cache, которая была создана ранее.
Я думал, что теперь можно спокойно удалить папку core/cache, что логично, ибо весь кэш же теперь будет в памяти, а не на фс. Но не тут-то было. Если эта папка пустая (или её нет) и в настройках включен apc, то php молча умирает (когда сохраняется ресурс или настройка. Больше ни с чем не экспериментировал). Отловить в логах нормальную ошибку с нормальным описанием у меня не получилось.
Чего-то ему видать не хватает.
Выработал порядок действий, при котором с apc всё работает нормально:
1. Установить cache_handler в xPDOFileCache.
2. Удалить папку core/cache.
3. Открыть любую страницу в админке, чтобы создались нужные файлы в кэше.
4. Установить cache_handler в cache.xPDOAPCCache.
5. Не удалять папку core/cache! :-)
Вот в такой последовательности всё работает. ХЗ почему так.
Это (кто бы мог подумать) — APC.
В общем, когда меняешь настройку обработчика кэша с xPDOFileCache на cache.xPDOAPCCache (cache_prefix, разумеется, задан), то всё работает в штатном режиме до тех пор, пока существует папка core/cache, которая была создана ранее.
Я думал, что теперь можно спокойно удалить папку core/cache, что логично, ибо весь кэш же теперь будет в памяти, а не на фс. Но не тут-то было. Если эта папка пустая (или её нет) и в настройках включен apc, то php молча умирает (когда сохраняется ресурс или настройка. Больше ни с чем не экспериментировал). Отловить в логах нормальную ошибку с нормальным описанием у меня не получилось.
Чего-то ему видать не хватает.
Выработал порядок действий, при котором с apc всё работает нормально:
1. Установить cache_handler в xPDOFileCache.
2. Удалить папку core/cache.
3. Открыть любую страницу в админке, чтобы создались нужные файлы в кэше.
4. Установить cache_handler в cache.xPDOAPCCache.
5. Не удалять папку core/cache! :-)
Вот в такой последовательности всё работает. ХЗ почему так.
а можно прописать обработчик кэша в конфиг и modx будет инициализировать сразу его…
Вот из-за подобных причуд я и бросил эксперименты с кэшерами, отличными от xPDOFileCache.
Странно, что с этой проблемой (именно с apc в modx) я стал первопроходцем)
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.