Het oplossen van de foutmelding "Bestand of map bestaat niet" die wordt veroorzaakt door inconsistenties tussen de Monit-monitoringconfiguratie en PHP-FPM.

Een bloedbad veroorzaakt door een socketpad.

Het verhaal gaat als volgt.

Ik heb een vriend wiens server vorige maand weer is vastgelopen.

Hij kwam naar me toe en vertelde dat Monit steeds foutmeldingen gaf, namelijk dat het php-fpm-socketbestand niet gevonden kon worden. Daarna begon de service regelmatig opnieuw op te starten en de belasting liep enorm op. Om drie uur 's ochtends werd hij gebeld met een noodoproep om de server te repareren.

Ik zei toch dat je niet in paniek moest raken en dat je me de monitorlogs moest laten zien.

Toen ik ernaar keek, zag ik tot mijn verbazing dat het vol zat met dit soort fouten:

fout: Unix-socket /run/php/php8.4-fpm.sock verbindingsfout — Bestand of map bestaat niet fout: 'php8.4-fpm' failed protocol test [DEFAULT] at /run/php/php8.4-fpm.sock — Kan geen Unix-socket maken voor /run/php/php8.4-fpm.sock

Ik vroeg hem: "Waar is je socketbestand nu?"

Hij zei dat hij het niet wist, dus heb ik het gewoon met de standaardinstellingen geïnstalleerd.

Ik zei toch dat je moest wachten, ik ga het voor je nakijken.

Toen heb ik via SSH ingelogd en zag ik dat zijn socketbestand daadwerkelijk zo heette... /run/php/php8.4-fpm-etufo.org.sock.

Ik zei: "Vriend, je socketpad bestaat uit twee verschillende dingen; het zou een wonder zijn als ze met elkaar konden communiceren."

Vandaag zal ik dit stap voor stap uitleggen en een oplossing voor het probleem aandragen.

Je denkt dat surveillance je beschermt, maar in werkelijkheid schaadt het je.

Laten we beginnen met het bespreken van het meest voorkomende type fout in de monitorlogboeken.

Als je dit ziet:

Fout: Verbindingsfout bij Unix-socket /run/php/php8.4-fpm.sock — Bestand of map bestaat niet.

Dit geeft aan dat monit probeert de php-fpm-service via deze socket te detecteren, maar het bestand niet kan vinden.

Vervolgens zal monit proberen de service opnieuw op te starten, en de logbestanden zullen het volgende weergeven:

info: 'php8.4-fpm' probeert opnieuw op te starten info: 'php8.4-fpm' stoppen: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' starten: '/usr/sbin/service php8.4-fpm start'

Het ziet er best slim uit, toch? Het repareert zichzelf automatisch.

Maar het probleem is dat juist dat frequente herstarten de echte ramp is.

Stel je dit eens voor: wanneer php-fpm opnieuw opstart, worden alle lopende verzoeken onderbroken, kunnen alle sessies verloren gaan en moeten alle verbindingen opnieuw tot stand worden gebracht. Als het herhaaldelijk binnen korte tijd opnieuw opstart en faalt, zal de serverbelasting direct enorm toenemen.

De logbestanden zullen ook meer informatie onthullen, zoals dit:

fout: 'etufo.org' loadavg (15min) van 8.8 komt overeen met de resourcelimiet [loadavg (15min) > 8.0] fout: 'etufoHet CPU-systeemgebruik van .org van 33.9% komt overeen met de resourcelimiet [CPU-systeemgebruik > 30.0%].

De server was al zwaar belast, maar het monitoringsysteem bleef de service desondanks herhaaldelijk herstarten. Dit loste het probleem niet op, maar maakte het alleen maar erger.

De kern van het probleem: de sleutel en het slot passen niet.

Bij nadere beschouwing blijkt het probleem eigenlijk vrij eenvoudig.

Het socketpad dat is opgegeven in het monit-configuratiebestand is:/run/php/php8.4-fpm.sock

Het daadwerkelijke socketpad waarop php-fpm draait, is echter:/run/php/php8.4-fpm-etufo.org.sock

Als de ene functie bedoeld is om bestand A te detecteren, maar de andere in werkelijkheid bestand B detecteert, zal de detectie uiteraard mislukken.

Dit is zoiets.

Je hebt een sleutel, die in een andere kamer ligt opgesloten.

Je gebruikt je sleutel elke dag om de deur te openen, maar elke keer lukt het niet en dan zeg je dat het slot kapot is.

Het slot is niet kapot, alleen past uw sleutel niet in het slot.

oplossenMonitor monitoringConfiguratie niet compatibel met PHP-FPM

Optie 1: Wijzig de monitorconfiguratie.

Als je de bestaande socketconfiguratie van php-fpm wilt behouden, pas dan de monit-configuratie aan.

Zoek het monit-configuratiebestand op en wijzig het volgende:

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

Verander het in:

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

Voer vervolgens een herlaadactie uit:

sudo monit reload

Dat is alles.

Optie 2: Wijzig de php-fpm-configuratie.

Als je het standaardpad wilt gebruiken, wijzig dan de poolconfiguratie van php-fpm.

Bewerk /etc/php/8.4/fpm/pool.d/chenweiliang.com.confWijzig het luistercommando naar:

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

Start vervolgens php-fpm opnieuw op:

sudo systemctl restart php8.4-fpm

Dat is alles.

Beide oplossingen kunnen het probleem verhelpen; welke je kiest, hangt af van je specifieke omstandigheden.

Hoeveel websites worden er op uw server gehost? Heeft elke website een eigen socket? Als er maar één website is, is het standaardpad eenvoudiger.

Laat me vanuit mijn hart spreken.

Ik ben er oprecht van overtuigd dat dit soort configuratieproblemen het gemakkelijkst over het hoofd worden gezien, maar tegelijkertijd de grootste impact hebben op de serverstabiliteit tijdens onderhoud.

Als een socketpad onjuist is geschreven, lijkt alles misschien rustig aan de oppervlakte, maar in werkelijkheid geeft het monitoringsysteem voortdurend valse alarmen, start de service willekeurig opnieuw op en piekt de belasting onverklaarbaar.

Je denkt misschien dat de server te oud is en een upgrade nodig heeft, maar het kan ook zijn dat het pad in het configuratiebestand onjuist is.

Zoals een senior collega ooit zei: "De nauwkeurigheid van de monitoring is de eerste verdedigingslinie om de stabiliteit van de dienstverlening te waarborgen."

Details bepalen succes of mislukking, en dat geldt absoluut in een serveromgeving.

Controleer vanaf vandaag uw monitoringconfiguratie. Laat dit ogenschijnlijk simpele probleem uw server niet platleggen.

Bedankt voor het lezen van mijn artikel. Tot de volgende keer.