На post запросах отваливается php5-fpm

Всем привет!

Если обычно в вопросах, касаемых 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
Алексей Карташов
22 октября 2014, 16:01
modx.pro
7 727
0

Комментарии: 6

Алексей Карташов
22 октября 2014, 20:02
0
.
    Василий Наумкин
    22 октября 2014, 21:39
    0
    502 — это общая ошибка, когда nginx спросил, а php не ответил.
    reset by peer — это когда php не ответил вообще. То есть, просто взял и умер, безо всяких таймаутов, или с ними — не важно. Главное, что помер.

    Соответственно, искать тебе нужно, отчего php неожиданно заворачивает ласты. Для этого нужно понять, когда именно он это делает?

    При сохранении ресурсов? А что там происходит, какие есть плагины на сохранение?
    Повторяется ли ситуация при сохранении сниппета? А системной настройки?

    Таким образом, потихоньку, сужай круг подозреваемых. Ну и, конечно, включи подробнейшие логи везде, где можно.

    У меня была такая точно такая же ошибка, когда я сам в одном из скриптов перезапускал php и очень удивлялся, отчего при выполнении этого скрипта процесс всегда падает =) Понятно дело, в логах было чисто, а php reset by peer и 502 в nginx.
      Алексей Карташов
      25 октября 2014, 00:11
      +1
      В общем, нашёл виновника.

      Это (кто бы мог подумать) — 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! :-)

      Вот в такой последовательности всё работает. ХЗ почему так.
        Володя
        25 октября 2014, 00:36
        0
        а можно прописать обработчик кэша в конфиг и modx будет инициализировать сразу его…
          Василий Наумкин
          25 октября 2014, 09:56
          0
          Вот из-за подобных причуд я и бросил эксперименты с кэшерами, отличными от xPDOFileCache.
            Алексей Карташов
            25 октября 2014, 20:35
            0
            Странно, что с этой проблемой (именно с apc в modx) я стал первопроходцем)
        Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
        6