Zgjidhja e gabimit "Nuk ka skedar ose direktori të tillë" të shkaktuar nga mospërputhjet midis konfigurimit të monitorimit të Monit dhe PHP-FPM.

Një gjakderdhje e shkaktuar nga një shteg foleje

Historia shkon kështu.

Kam një mik, serveri i të cilit u bllokua përsëri muajin e kaluar.

Ai erdhi tek unë dhe tha që monit vazhdonte të raportonte gabime, duke thënë se nuk mund ta gjente skedarin socket php-fpm, dhe pastaj shërbimi filloi të rinisej shpesh, dhe ngarkesa vazhdoi të rritej shumë. Në orën tre të mëngjesit, ai u thirr nga një telefonatë emergjence për të rregulluar serverin.

Të thashë të mos bësh panik dhe të më tregosh regjistrat e monitorimit.

Kur e pashë, uau, ishte plot me këto lloj gabimesh:

gabim: Gabim lidhjeje në socket Unix /run/php/php8.4-fpm.sock — Nuk ka skedar ose direktori të tillë gabim: 'php8.4-fpm' faitesti i protokollit LED [PARAPRAKISHT] në /run/php/php8.4-fpm.sock — Nuk mund të krijohet socket unix për /run/php/php8.4-fpm.sock

E pyeta, "Ku është skedari juaj socket tani?"

Ai tha që nuk e dinte, kështu që unë thjesht e instalova me cilësimet fillestare.

Të thashë të prit, do të kontrolloj për ty.

Pastaj u futa në SSH dhe pashë që skedari i tij i vërtetë socket quhej... /run/php/php8.4-fpm-etufo.org.sock.

I thashë, shoku, shtegu i soketit tënd është dy gjëra të ndryshme, do të ishte një mrekulli nëse do të mund të komunikonte.

Sot do ta analizoj dhe shpjegoj në detaje këtë problem, si dhe do të jap një zgjidhje.

Ti mendon se mbikëqyrja po të mbron, por në të vërtetë po të dëmton.

Le të fillojmë duke folur për llojin më të zakonshëm të gabimit në regjistrat e monitorimit.

Kur e shihni këtë:

gabim: Gabim lidhjeje në socket Unix /run/php/php8.4-fpm.sock — Nuk ka skedar ose direktori të tillë

Kjo tregon që monit po përpiqet të zbulojë shërbimin php-fpm përmes këtij socket-i, por nuk mund ta gjejë skedarin.

Ajo që ndodh më pas është se monitori do të përpiqet të rinisë shërbimin dhe regjistrat do të tregojnë:

info: 'php8.4-fpm' duke u përpjekur të rinisë info: 'php8.4-fpm' stop: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' start: '/usr/sbin/service php8.4-fpm start'

Duket mjaft elegante, apo jo? Riparohet vetë automatikisht.

Por problemi është se kjo rinisje e shpeshtë është katastrofa e vërtetë.

Imagjinoni këtë: kur php-fpm riniset, të gjitha kërkesat që janë duke u përpunuar aktualisht ndërpriten, të gjitha seancat mund të humbasin dhe të gjitha lidhjet duhet të rivendosen. Nëse riniset vazhdimisht dhe dështon brenda një periudhe të shkurtër kohore, ngarkesa e serverit do të rritet menjëherë.

Regjistrat do të zbulojnë gjithashtu më shumë informacion, si ky:

gabim: 'etufo.org' loadavg (15min) nga 8.8 përputhet me limitin e burimeve [loadavg (15min) > 8.0] gabim: 'etufoPërdorimi i sistemit të CPU-së .org' prej 33.9% përputhet me limitin e burimeve [përdorimi i sistemit të CPU-së > 30.0%]

Serveri ishte tashmë nën ngarkesë të lartë, por sistemi i monitorimit vazhdonte ta riniste shërbimin në mënyrë të përsëritur. Kjo nuk po shuante një zjarr; po i hidhte benzinë ​​zjarrit.

Thelbi i problemit: çelësi dhe bllokimi nuk përputhen.

Pas një analize më të afërt, problemi është në fakt mjaft i thjeshtë.

Shtegu i soketit i specifikuar në skedarin e konfigurimit të monit është:/run/php/php8.4-fpm.sock

Megjithatë, shtegu aktual i soketit në të cilin funksionon php-fpm është:/run/php/php8.4-fpm-etufo.org.sock

Nëse një funksion ka për qëllim të zbulojë skedarin A, por tjetri është në të vërtetë skedari B, zbulimi padyshim që do të dështojë.

Kjo është si diçka.

Ke një çelës, të kyçur në një dhomë tjetër.

Ti përdor çelësin për të hapur derën çdo ditë, por sa herë që e gjen nuk hapet, dhe pastaj thua se brava është e prishur.

Në fakt, brava nuk është e thyer; thjesht çelësi yt nuk përputhet me bravën.

zgjidhMonitoroni monitoriminKonfigurimi nuk është në përputhje me PHP-FPM

Opsioni 1: Ndryshoni konfigurimin e monitorit.

Nëse doni të ruani konfigurimin ekzistues të socket-it të php-fpm, atëherë modifikoni konfigurimin e monit.

Gjeni skedarin e konfigurimit të monit dhe modifikoni sa vijon:

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

Ndryshojeni në:

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

Pastaj kryeni një ringarkim:

sudo monit reload

Kaq ishte.

Opsioni 2: Ndryshoni konfigurimin php-fpm.

Nëse doni të përdorni shtegun e parazgjedhur, atëherë ndryshoni konfigurimin e pishinës së php-fpm.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confNdrysho komandën listen në:

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

Pastaj rinisni php-fpm:

sudo systemctl restart php8.4-fpm

Kaq ishte.

Të dyja zgjidhjet mund ta zgjidhin problemin; se cilën zgjidhni varet nga rrethanat tuaja specifike.

Sa faqe interneti janë të hostuara në serverin tuaj? A ka secila faqe një socket të pavarur? Nëse ka vetëm një faqe interneti, rruga e parazgjedhur do të jetë më e thjeshtë.

Më lejoni të flas nga zemra.

Unë besoj sinqerisht se këto lloje problemesh të konfigurimit janë ato që anashkalohen më lehtë, por që kanë më shumë ndikim në stabilitetin e serverit gjatë mirëmbajtjes.

Nëse një shteg soketi është shkruar gabimisht, gjërat mund të duken të qeta në sipërfaqe, por në realitet, sistemi i monitorimit vazhdon të japë alarme të rreme, shërbimi vazhdon të riniset rastësisht dhe ngarkesa vazhdon të rritet në mënyrë të pashpjegueshme.

Mund të mendoni se serveri është shumë i vjetër dhe ka nevojë për një përmirësim, por në fakt mund të jetë që rruga në skedarin e konfigurimit është e gabuar.

Siç tha dikur një koleg i lartë, "Saktësia e monitorimit është vija e parë e mbrojtjes për të siguruar stabilitetin e shërbimit".

Detajet përcaktojnë suksesin ose dështimin, dhe kjo është absolutisht e vërtetë në një mjedis serveri.

Duke filluar nga sot, kontrolloni konfigurimin e monitorimit. Mos lejoni që ky problem në dukje i thjeshtë të shkaktojë probleme me serverin tuaj.

Faleminderit që lexuat artikullin tim. Shihemi herën tjetër.