Решавање на грешката „Нема таква датотека или директориум“ предизвикана од недоследности помеѓу конфигурацијата за следење на Monit и PHP-FPM.

Крвопролевање предизвикано од патека на сокет

Приказната оди вака.

Имам пријател чиј сервер повторно се расипа минатиот месец.

Тој дојде кај мене и ми рече дека monit постојано пријавува грешки, велејќи дека не може да ја пронајде php-fpm сокет-датотеката, а потоа услугата почнала често да се рестартира, а оптоварувањето постојано се зголемувало. Во три часот наутро, бил повикан од итен повик за да го поправи серверот.

Ти реков да не паничиш и да ми ги покажеш логовите за мониторинг.

Кога го погледнав, воау, беше полн со вакви грешки:

грешка: Грешка во поврзувањето со Unix socket /run/php/php8.4-fpm.sock — Не постои таква датотека или директориум грешка: 'php8.4-fpm' faiтест на протоколот со LED диода [СТАНДАЛНО] на /run/php/php8.4-fpm.sock — Не може да се креира unix сокет за /run/php/php8.4-fpm.sock

Го прашав: „Каде ти е сега сокет-датотеката?“

Тој рече дека не знае, па затоа го инсталирав со стандардните поставки.

Ти реков да почекаш, ќе проверам за тебе.

Потоа се вклучив во SSH и видов дека неговата вистинска сокет-датотека се вика... /run/php/php8.4-fpm-etufo.org.sock.

Реков, другар, твојата патека на сокетот е две различни работи, би било чудо ако може да комуницира.

Денес ќе го разложам ова и ќе го објаснам детално, а исто така ќе понудам и решение за проблемот.

Мислиш дека надзорот те штити, а всушност ти штети.

Да почнеме со тоа што ќе разговараме за најчестиот тип на грешка во дневниците за мониторинг.

Кога ќе го видите ова:

грешка: Грешка при поврзување со Unix socket /run/php/php8.4-fpm.sock — Нема таква датотека или директориум

Ова покажува дека monit се обидува да ја детектира услугата php-fpm преку овој сокет, но не може да ја пронајде датотеката.

Следно што се случува е дека monitor ќе се обиде да ја рестартира услугата, а логовите ќе покажат:

info: 'php8.4-fpm' се обидува да рестартира info: 'php8.4-fpm' stop: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' start: '/usr/sbin/service php8.4-fpm start'

Изгледа доста паметно, нели? Се поправа сам по себе автоматски.

Но, проблемот е што ова често рестартирање е вистинска катастрофа.

Замислете го ова: кога php-fpm ќе се рестартира, сите барања што се обработуваат во моментов се прекинати, сите сесии може да бидат изгубени и сите врски треба да се воспостават повторно. Ако постојано се рестартира и не успее во краток период, оптоварувањето на серверот веднаш ќе се зголеми.

Дневниците исто така ќе откријат повеќе информации, како на пример ова:

грешка: 'етНЛО.org' loadavg (15мин) од 8.8 се совпаѓа со ограничувањето на ресурсите [loadavg (15мин) > 8.0] грешка: 'etНЛОКористењето на процесорот од 33.9% на .org се совпаѓа со ограничувањето на ресурсите [користење на процесорот > 30.0%]

Серверот веќе беше под големо оптоварување, но системот за следење сè уште постојано ја рестартираше услугата. Ова не гаснеше пожар; туку додаваше масло на огнот.

Суштината на проблемот: клучот и бравата не се совпаѓаат.

По подетална анализа, проблемот е всушност прилично едноставен.

Патеката на сокетот наведена во конфигурациската датотека на monit е:/run/php/php8.4-fpm.sock

Сепак, вистинската патека на сокетот на која работи php-fpm е:/run/php/php8.4-fpm-etufo.org.sock

Ако едната функција е наменета за откривање на датотеката А, но другата е всушност датотеката Б, откривањето очигледно ќе биде неуспешно.

Ова е како нешто.

Имаш клуч, заклучен во друга соба.

Секој ден го користиш клучот за да ја отвориш вратата, но секој пат кога ќе откриеш дека не се отвора, а потоа велиш дека бравата е скршена.

Всушност, бравата не е скршена; само што твојот клуч не се совпаѓа со бравата.

решиСледете го мониторинготКонфигурацијата е неконзистентна со PHP-FPM

Опција 1: Променете ја конфигурацијата на мониторот.

Ако сакате да ја задржите постоечката конфигурација на сокетот на php-fpm, тогаш изменете ја конфигурацијата на monit.

Лоцирајте ја конфигурациската датотека monit и изменете го следново:

if failed unixsocket /run/php/php8.4-fpm.sock then restart

Смени во:

if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart

Потоа извршете повторно полнење:

sudo monit reload

Тоа е тоа.

Опција 2: Променете ја конфигурацијата php-fpm.

Ако сакате да ја користите стандардната патека, тогаш променете ја конфигурацијата на базенот на php-fpm.

Уредување /etc/php/8.4/fpm/pool.d/chenweiliang.com.confПроменете ја командата listen во:

listen = /run/php/php8.4-fpm.sock

Потоа рестартирајте го php-fpm:

sudo systemctl restart php8.4-fpm

Тоа е тоа.

И двете решенија можат да го решат проблемот; кое ќе го изберете зависи од вашите специфични околности.

Колку страници се хостирани на вашиот сервер? Дали секоја страница има независен сокет? Ако има само една страница, стандардната патека ќе биде поедноставна.

Дозволете ми да зборувам од срце.

Искрено верувам дека овие типови проблеми со конфигурацијата најлесно се занемаруваат, но сепак имаат најголемо влијание врз стабилноста на серверот за време на одржувањето.

Ако патеката на сокетот е напишана неправилно, работите може да изгледаат мирно на површината, но всушност, системот за следење продолжува да дава лажни аларми, услугата продолжува да се рестартира случајно, а оптоварувањето продолжува необјасниво да расте.

Можеби мислите дека серверот е премногу стар и му треба надградба, но всушност може да биде дека патеката во конфигурациската датотека е погрешна.

Како што еднаш рече еден постар колега, „Точноста на мониторингот е првата линија на одбрана за обезбедување стабилност на услугата“.

Деталите го одредуваат успехот или неуспехот, а ова е апсолутно точно во серверска средина.

Почнувајќи од денес, проверете ја вашата конфигурација за следење. Не дозволувајте овој навидум едноставен проблем да го сруши вашиот сервер.

Ви благодарам што ја прочитавте мојата статија. Се гледаме следниот пат.