Monit monitorizazio konfigurazioaren eta PHP-FPMren arteko inkoherentzien ondorioz sortutako "Ez dago fitxategi edo direktoriorik" errorea konpontzen.

Entxufe-bide batek eragindako odol-bainua

Istorioa honela doa.

Lagun bat daukat bere zerbitzaria berriro kraskatu zitzaion joan den hilabetean.

Niregana etorri zen eta esan zidan monitek erroreak salatzen zituela etengabe, php-fpm socket fitxategia ezin zuela aurkitu esanez, eta gero zerbitzua maiz berrabiarazten hasi zela, eta karga izugarri handitzen ari zela. Goizeko hiruretan, larrialdi dei batek deitu zion zerbitzaria konpontzeko.

Esan nizun ez izutzeko eta monitore-erregistroak erakusteko.

Begiratu nionean, harrigarria, akats mota hauez beteta zegoen:

errorea: Unix socket /run/php/php8.4-fpm.sock konexio errorea — Ez dago halako fitxategi edo direktoriorik errorea: 'php8.4-fpm' failed protokolo proba [LEHENTSA] /run/php/php8.4-fpm.sock helbidean — Ezin da unix socket bat sortu /run/php/php8.4-fpm.sock-erako

Galdetu nion, "Non dago zure socket fitxategia orain?"

Ez zekiela esan zuen, beraz, lehenetsitako ezarpenekin instalatu nuen.

Itxaroteko esan nizun, nik begiratuko dizut.

Gero SSH bidez sartu nintzen eta ikusi nuen bere benetako socket fitxategia deitzen zela... /run/php/php8.4-fpm-etufo.org.sock.

Esan nuen, lagun, zure socket bidea bi gauza desberdin dira, miraria litzateke komunikatu ahal izango balitz.

Gaur, hau guztia xehetasunez azalduko dut, eta baita arazoari irtenbidea emango ere.

Zaintziak babesten zaituela uste duzu, baina benetan kalte egiten dizu.

Has gaitezen monitore-erregistroetan ohikoena den errore motaz hitz egiten.

Hau ikusten duzunean:

errorea: Unix socket /run/php/php8.4-fpm.sock konexio errorea — Ez dago halako fitxategi edo direktoriorik

Honek adierazten du monit-ek php-fpm zerbitzua socket honen bidez detektatzen saiatzen ari dela, baina ezin duela fitxategia aurkitu.

Ondoren gertatzen dena da monit-ek zerbitzua berrabiarazten saiatuko dela, eta erregistroek hau erakutsiko dute:

info: 'php8.4-fpm' berrabiarazten saiatzen info: 'php8.4-fpm' stop: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' start: '/usr/sbin/service php8.4-fpm start'

Nahiko adimentsua dirudi, ezta? Automatikoki konpontzen da.

Baina arazoa da berrabiarazte maiz hori dela benetako hondamendia.

Imajinatu hau: php-fpm berrabiarazten denean, une honetan prozesatzen ari diren eskaera guztiak eten egiten dira, saio guztiak gal daitezke eta konexio guztiak berrezarri behar dira. Denbora gutxian behin eta berriz berrabiarazten bada eta huts egiten badu, zerbitzariaren karga berehala igoko da.

Erregistroek informazio gehiago ere agerian utziko dute, hala nola hau:

errorea: 'etaUFO.org' 8.8ko loadavg (15min) baliabideen mugarekin bat dator [loadavg (15min) > 8.0] errorea: 'etUFO.org-en CPU sistemaren erabilera % 33.9koa baliabideen mugarekin bat dator [CPU sistemaren erabilera > % 30.0]

Zerbitzaria karga handiaren pean zegoen jada, baina monitorizazio-sistemak zerbitzua behin eta berriz berrabiarazten zuen. Honek ez zuen sua itzaltzen; suari erregaia gehitzen zion.

Arazoaren funtsa: giltza eta giltzarrapoa ez datoz bat.

Azterketa sakonago baten ondoren, arazoa nahiko sinplea da, egia esan.

Monit konfigurazio fitxategian zehaztutako socket bidea hau da:/run/php/php8.4-fpm.sock

Hala ere, php-fpm-k exekutatzen duen socket bidea hau da:/run/php/php8.4-fpm-etufo.org.sock

Funtzio bat A fitxategia detektatzeko bada, baina bestea B fitxategia bada, detekzioak huts egingo du, noski.

Hau zerbaiten antzekoa da.

Giltza bat duzu, beste gela batean giltzapetuta.

Egunero giltza erabiltzen duzu atea irekitzeko, baina aldi bakoitzean ez da irekitzen, eta orduan sarraila hautsita dagoela esaten duzu.

Egia esan, giltza ez dago hautsita; zure giltza ez dator bat giltzarrapoarekin, besterik ez.

konponduMonitorearen jarraipenaKonfigurazioa PHP-FPM-rekin bateraezina da

1. aukera: Monitorearen konfigurazioa aldatu.

php-fpm-ren socket konfigurazioa mantendu nahi baduzu, aldatu monit konfigurazioa.

Bilatu monit konfigurazio fitxategia eta aldatu honako hau:

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

Aldatu hona:

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

Ondoren, berriro kargatu:

sudo monit reload

Hori da dena.

2. aukera: php-fpm konfigurazioa aldatu.

Bide lehenetsia erabili nahi baduzu, aldatu php-fpm-ren multzoaren konfigurazioa.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confAldatu listen komandoa honetara:

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

Ondoren, berrabiarazi php-fpm:

sudo systemctl restart php8.4-fpm

Hori da dena.

Bi irtenbideek arazoa konpondu dezakete; zein aukeratzen duzun zure egoera zehatzaren araberakoa da.

Zenbat gune daude ostatatzen zure zerbitzarian? Gune bakoitzak socket independente bat al du? Gune bakarra badago, bide lehenetsia errazagoa izango da.

Bihotzetik hitz egiten utzi iezadazu.

Benetan uste dut konfigurazio arazo mota hauek direla mantentze-lanetan zehar zerbitzariaren egonkortasunean eragin handiena dutenak, baina errazen ahaztu daitezkeenak.

Socket bide bat gaizki idazten bada, gauzak lasai daudela dirudi gainazalean, baina errealitatean, monitorizazio sistemak alarma faltsuak ematen jarraitzen du, zerbitzua ausaz berrabiarazten da eta karga azalpenik gabe igotzen da.

Zerbitzaria zaharregia dela eta berritzea behar duela pentsa dezakezu, baina konfigurazio fitxategiko bidea okerra izan daiteke.

Lankide beterano batek esan zuen bezala, "Monitorizazioaren zehaztasuna da zerbitzuaren egonkortasuna bermatzeko lehen defentsa-lerroa".

Xehetasunek zehazten dute arrakasta edo porrota, eta hori guztiz egia da zerbitzari-ingurune batean.

Gaurtik aurrera, egiaztatu zure monitorizazio konfigurazioa. Ez utzi itxuraz arazo sinple honek zure zerbitzaria kraskatzen.

Eskerrik asko nire artikulua irakurtzeagatik. Hurrengoan arte.