Løser feilen «Ingen slik fil eller katalog» som skyldes inkonsekvenser mellom Monit-overvåkingskonfigurasjonen og PHP-FPM.

Et blodbad utløst av en socketbane

Historien går slik.

Jeg har en venn som fikk serverkrasj igjen forrige måned.

Han kom til meg og sa at monit stadig rapporterte feil, at den ikke kunne finne php-fpm socket-filen, og så begynte tjenesten å starte på nytt ofte, og belastningen fortsatte å øke. Klokken tre om morgenen ble han oppringt av en nødtelefon for å fikse serveren.

Jeg sa at du ikke skulle få panikk og vise meg overvåkingsloggene.

Da jeg så på det, wow, det var fullt av denne typen feil:

feil: Unix socket /run/php/php8.4-fpm.sock tilkoblingsfeil — Ingen slik fil eller katalog feil: 'php8.4-fpm' f ai led protocol test [STANDARD] på /run/php/php8.4-fpm.sock — Kan ikke opprette unix socket for /run/php/php8.4-fpm.sock

Jeg spurte ham: «Hvor er socket-filen din nå?»

Han sa at han ikke visste det, så jeg bare installerte det med standardinnstillingene.

Jeg sa du skulle vente, så skal jeg sjekke for deg.

Så koblet jeg meg til med SSH og så at den faktiske socket-filen hans ble kalt... /run/php/php8.4-fpm-etufo.org.sock.

Jeg sa, kompis, sokkelbanen din er to forskjellige ting, det ville være et mirakel om den kunne kommunisere.

I dag skal jeg gå gjennom dette og forklare det i detalj, og også gi en løsning på problemet.

Du tror overvåking beskytter deg, men det skader deg faktisk.

La oss begynne med å snakke om den vanligste feiltypen i monit-loggene.

Når du ser dette:

feil: Unix socket /run/php/php8.4-fpm.sock tilkoblingsfeil — Filen eller katalogen finnes ikke

Dette indikerer at monit prøver å oppdage php-fpm-tjenesten gjennom denne sokkelen, men den finner ikke filen.

Det som skjer videre er at monit vil forsøke å starte tjenesten på nytt, og loggene vil vise:

info: 'php8.4-fpm' prøver å starte på nytt info: 'php8.4-fpm' stop: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' start: '/usr/sbin/service php8.4-fpm start'

Det ser ganske smart ut, ikke sant? Den reparerer seg selv automatisk.

Men problemet er at denne hyppige omstarten er den virkelige katastrofen.

Tenk deg dette: når php-fpm starter på nytt, blir alle forespørsler som behandles avbrutt, alle økter kan gå tapt, og alle tilkoblinger må gjenopprettes. Hvis den gjentatte ganger starter på nytt og feiler i løpet av kort tid, vil serverbelastningen øke umiddelbart.

Loggene vil også avsløre mer informasjon, som for eksempel dette:

feil: 'et ufo .org' loadavg (15min) på 8.8 samsvarer med ressursgrensen [loadavg (15min) > 8.0] feil: 'et ufo .org' CPU-systembruk på 33.9 % samsvarer med ressursgrensen [CPU-systembruk > 30.0 %]

Serveren var allerede under høy belastning, men overvåkingssystemet startet tjenesten på nytt gjentatte ganger. Dette slukket ikke en brann, det hældte bensin på bålet.

Kjernen i problemet: nøkkelen og låsen stemmer ikke overens.

Ved nærmere analyse er problemet faktisk ganske enkelt.

Socket-banen som er spesifisert i monit-konfigurasjonsfilen er:/run/php/php8.4-fpm.sock

Den faktiske socket-stien som php-fpm kjører på er imidlertid:/run/php/php8.4-fpm-etufo.org.sock

Hvis én funksjon er ment å oppdage fil A, men den andre faktisk er fil B, vil deteksjonen åpenbart mislykkes.

Dette er liksom noe.

Du har en nøkkel, låst i et annet rom.

Du bruker nøkkelen din til å åpne døren hver dag, men hver gang oppdager du at den ikke vil åpne seg, og så sier du at låsen er ødelagt.

Låsen er faktisk ikke ødelagt; det er bare at nøkkelen din ikke passer til låsen.

løseMonit overvåkingKonfigurasjon inkonsekvent med PHP-FPM

Alternativ 1: Endre skjermkonfigurasjonen.

Hvis du vil beholde den eksisterende socket-konfigurasjonen til php-fpm, må du endre monit-konfigurasjonen.

Finn konfigurasjonsfilen for monit og endre følgende:

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

Endre det til:

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

Utfør deretter en omlasting:

sudo monit reload

Det er det.

Alternativ 2: Endre php-fpm-konfigurasjonen.

Hvis du vil bruke standardstien, må du endre pool-konfigurasjonen til php-fpm.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confEndre lyttekommandoen til:

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

Start deretter php-fpm på nytt:

sudo systemctl restart php8.4-fpm

Det er det.

Begge løsningene kan løse problemet; hvilken du velger avhenger av dine spesifikke omstendigheter.

Hvor mange nettsteder ligger på serveren din? Har hvert nettsted en uavhengig socket? Hvis det bare er ett nettsted, vil standardstien være enklere.

La meg snakke fra hjertet.

Jeg tror virkelig at denne typen konfigurasjonsproblemer er de som lettest blir oversett, men som likevel har størst innvirkning på serverstabiliteten under vedlikehold.

Hvis en socket-sti er skrevet feil, kan ting virke rolige på overflaten, men i virkeligheten fortsetter overvåkingssystemet å gi falske alarmer, tjenesten starter på nytt tilfeldig, og belastningen fortsetter å øke uforklarlig.

Du tror kanskje at serveren er for gammel og trenger en oppgradering, men det kan faktisk være at banen i konfigurasjonsfilen er feil.

Som en seniorkollega en gang sa: «Nøyaktigheten i overvåkingen er den første forsvarslinjen for å sikre tjenestestabilitet.»

Detaljer avgjør suksess eller fiasko, og dette er absolutt sant i et servermiljø.

Fra og med i dag bør du sjekke overvåkingskonfigurasjonen din. Ikke la dette tilsynelatende enkle problemet krasje serveren din.

Takk for at du leste artikkelen min. Vi sees neste gang.