php fpm sock отсутствует
Настраиваем работу php-fpm на порт или на сокет
Предыстория
Решил сегодня обновить свой сервачёк до php7.3, у меня была 7.2. А как говорится — лучшее враг хорошего и положил всё на пару часов. Казалось бы простая команда
Не забываем, что тут всё начинается с решетки, т.е. от суперпользователя. Но что-то пошло не так, и я на выходе получил 502 Bad Gateway. Всё очевидно. Что-то с моими воротами не так, а вот что, не очень понятно. Да, у меня настроена связка php + nginx — я взрослый и с Апачами не вожусь.
Чиним
Потратил относительно много времени, чтобы починиться. Гуглил и саму проблему, что по идее не проблема, а просто nginx почему-то ходит не туда куда надо. Хотя ещё минуту назад с php7.2 он ходил туда же, но ничего не находил. Опуская детали, у меня nginx был настроен вот так
Что как бы намекает, что nginx лезет на 9000 порт, но вот
как бы намекает, что на этом порту у меня нет никого от слова совсем-вообще. А чтобы постичь следующую мудрость мне потребовалось 2 часа моего личного времени.
Как видно из заголовка поста FPM умеет быть в двух разных ипостасях: жить на tcp порту и на сокете (Я не силён в теории сетей, поэтому примем этот факт как аксиому). Для nginx’а нужно было чтобы приемник жил на порту с номером 9000. Технически ему по барабану кто на том конце сидит, он свое дело делает как умеет, пересылает туда куда написано. А вот приемник в лице php-fpm отчего-то не захотел подниматься, хотя когда в прошлый раз настраивал оно как-то само всё заработало без моей помощи… кажется…
Итого. Всякими страшными заклинаниями я постиг истину.
Чтобы php-fpm жил на порту
Нужно в /etc/php/7.3/fpm/pool.d/www.conf писать так
Остальные директивы listen либо закомментировать (точка с запятой в начале строки), либо удалить. Тогда верхний конфиг будет работать нормально.
А чтобы php-fpm жил на сокете
Нужно в /etc/php/7.3/fpm/pool.d/www.conf писать так
Скорее всего оно так написано по умолчанию. Ещё рекомендуют раскомментировать
Типа, чтобы запросы только от локлхоста обрабатывались. При этом в конфигах nginx надо перенаправлять запросы на этот самый сокет
Обрати внимание на директиву fastcgi_pass, в первом и втором случае она принципиально отличаются.
У меня есть сервер AWS на Amazon Linux.
7 ответов
Изменить: реальное решение здесь заключается в том, что прослушивание в www.conf и fastcgi_pass в конфигурации nginx должно совпадать. Используете ли вы сокеты или TCP, решать вам.
В /etc/php-fpm.d/www.conf есть:
Итак, в моей конфигурации nginx я поставил
Вместо использования чего-то вроде
Надеюсь это поможет!
Убедитесь, что у вас есть следующая папка и что она доступна для записи. /var/run/php-fpm
затем в www.conf вы помещаете: listen = /var/run/php-fpm/php-fpm.sock
затем запустите: sudo service php-fpm restart
У меня была ошибка, потому что я скопировал pool.d / xx.conf, и у нового было такое же имя пула [что угодно], поэтому второй не был загружен. Ни ошибки, ни сокета.
Надеюсь, что это помогает кому-то 🙂
Я только что скопировал и вставил файл пула и изменил только имя сокета в разделе прослушивания. Нет розетки.
Это произошло потому, что имя пула уже использовалось. Если у вас уже есть пул с таким же именем, новый сокет не создается.
Поэтому важно иметь уникальное имя пула для каждого сокета.
Итак, при копировании / вставке конфигурации пула: измените имя пула и имя сокета!
В моем случае я пропустил в /etc/php/7.0/fpm/pool.d/wordpress.conf правильный раздел
Я знаю, что уже слишком поздно, но, может быть, это поможет. Вы можете создать новый файл блокировки с нуля, используя Python.
How to find my php-fpm.sock?
I’m running WordPress with: Nginx + PHP-FPM + APC + W3 Total Cache + PageSpeed.
After 3 days researching and configuring, I succeeded to make it work. I configured PHP-FPM to run via 127.0.0.1:9000. But now I want to configure via Socket.
Running whereis php-fpm the output is:
But there isn’t any php-fpm.sock there.
6 Answers 6
I know this is old questions but since I too have the same problem just now and found out the answer, thought I might share it. The problem was due to configuration at pool.d/ directory.
Restart both nginx and php5-fpm service afterwards and check if php5-fpm.sock already created.
I faced this same issue on CentOS 7 years later
Posting hoping that it may help others.
Steps:
FIRST, configure the php-fpm settings:
-> systemctl stop php-fpm.service
-> cp www.conf www.conf.backup (back file up just in case)
-> :/listen = (to get to the line we need to change)
-> i (to enter VI’s text insertion mode)
-> change from listen = 127.0.0.1:9000 TO listen = /var/run/php-fpm/php-fpm.sock
-> Esc then :/listen.owner (to find it) then i (to change)
-> UNCOMMENT the listen.owner = nobody AND listen.group = nobody lines
-> Hit Esc then type :/user = then i
-> change user = apache TO user = nginx
-> AND change group = apache TO group = nginx
-> Hit Esc then :wq (to save and quit)
-> systemctl start php-fpm.service (now you will have a php-fpm.sock file)
SECOND, you configure your server <> block in your /etc/nginx/nginx.conf file. Then run: systemctl restart nginx.service
-> (PHP page will print date and day in browser)
I have an AWS server running on Amazon Linux.
8 Answers 8
Make sure you have the following folder and that it’s writable. /var/run/php-fpm
then in your www.conf you put: listen = /var/run/php-fpm/php-fpm.sock
then run: sudo service php-fpm restart
Edit: The real solution here is that the listen in www.conf and fastcgi_pass in nginx configuration have to match. Whether you use sockets or tcp is up to you.
in /etc/php-fpm.d/www.conf it has:
So in my nginx config I put
Instead of using something like
I had just copy-pasted a pool-file, and only changed the socket-name in the listen-section. No socket.
This was because the pool name was already in use. When you already have pool with the same name, then there is not created a new socket.
So it is important to have a unique pool name for each socket.
So when copy/paste a pool configuration: Change both pool-name and socket-name!
I know its too late, but may be this can help. You can create a new lock file from the scratch using Python.
In my case, I missed in /etc/php/7.0/fpm/pool.d/wordpress.conf the correct section
The *.sock file is not created from filename but from section name.
php-fpm перестает отвечать на запросы, и плодит кучу процессов.
Есть довольно мощный сервер (выделенный, 4-ядра ксеон, 32 памяти, SSD). На котором по не понятной причине перестает работать php-fpm. В какое-то время он просто перестает отвечать на запросы, а в процессах висит куча его пулов.
В логах кроме ошибок nginx ничего нету (php5-fpm лог чистый)
и все в таком духе
конфиг /etc/php5/fpm/pool.d/www.conf (коменты удалены)
конфиг /etc/php5/fpm/php-fpm.conf (коменты удалены)
До недавнего времени, работал на сокетах. Но поскольку проблема проявляется стабильно, попробовал перевести на порты. Результата нет. Не могу понять в чем проблема.
плодит кучу процессов.
Connection timed out
PHP-скрипты работают слишком долго, запросы не успевают отрабатываться.
Для начала — что-то типа
Или под высокой нагрузкой даже меньше, 3-5 сек.
в соответствующем php.ini
и памяти там достаточно.
По логике, суть ситуации в том, что у меня просто выбираются все свободные chldren (которых 200 штук), и новые просто не могут создаться.
Но я не понимаю чем они заняты, и как это посмотреть?
Вот когда у тебя скрипты подвисают, они и ждут по часу каждый 🙂
Но я не понимаю чем они заняты, и как это посмотреть?
Поставь 5-10-30 секунд. И лови в логах, в каком месте будет ошибка вылетать.
Более точно можно понять с установкой xhprof или xdebug (важно помнить, что когда последний подключен к PHP то тормозит скорость работы почти в 10 раз даже когда выключен).
xdebug (важно помнить, что когда последний подключен к PHP то тормозит скорость работы почти в 10 раз даже когда выключен).
И место на харде быстро заканчивается.
Была такая же трабла с OwenCloud, решилось с обновлением ОС. Полагаю, что проблема в коде.
а может просто к примеру база занимает время и процесс поэтому висит?
Ну у меня счас одно предположение.
Гдето (пока не знаю) где, косяк в коде, который вызывает зацикливание (или просто очень долгую отработку), в какой-то момент, кто-то или что-то, начинает вызывать этот косяк, отсюда забивается все 200 чилдренов, и на нового чилдрена просто нет ресурса.
И место на харде быстро заканчивается.
При выключенном автостарте xdebug — нет 🙂 Но вот скорость падает сильно. Поэтому под нагрузкой — только xhprof.