Het verwijderen van de NGINX-cache plaatst kritieke ontkoppelingsfouten in het foutenlogboek

Gepubliceerd: 15 februari 2025 om 11:24:34 UTC

Dit artikel legt uit hoe u items uit de cache van NGINX verwijdert zonder dat uw logbestanden vol staan met foutmeldingen. Hoewel dit over het algemeen geen aanbevolen aanpak is, kan het in sommige randgevallen nuttig zijn.

Deze pagina is machinaal uit het Engels vertaald om hem voor zoveel mogelijk mensen toegankelijk te maken. Helaas is machinevertaling nog geen geperfectioneerde technologie, dus er kunnen fouten optreden. Als je dat liever hebt, kun je hier de originele Engelse versie bekijken:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

De informatie in dit bericht is gebaseerd op FastCGI-caching op NGINX 1.4.6 dat draait op Ubuntu Server 14.04 x64. Het kan wel of niet geldig zijn voor andere versies.

(Update 2025: In de tijd tussen het schrijven van de originele post en nu is er veel veranderd. Servers zijn sneller en goedkoper, dus ik zou de aanpak die in deze post wordt beschreven, waarbij ik probeer de cache-vervaldatum te micromanagen om een paar extra generaties dynamische content te besparen, niet aanbevelen. Ik laat de content hier staan voor toekomstige referentie en voor het geval iemand het om wat voor reden dan ook daadwerkelijk nodig heeft. Ik heb nog niet bevestigd dat dit nog steeds werkt voor huidige versies van NGINX, maar ik denk van wel.)

Nadat ik een aantal sites van Apache naar NGINX had gemigreerd, ben ik erg gesteld geraakt op de ingebouwde cachemogelijkheden. Deze werken in de meeste gevallen uitstekend, zonder dat ik er veel moeite voor hoef te doen.

Voor een van de sites had ik echter echt de mogelijkheid nodig om de cache zelf te wissen (zowel volledig als afzonderlijke vermeldingen te verwijderen). De gratis community-editie van NGINX ondersteunt alleen op tijd gebaseerde cachevervaldatum (d.w.z. u kunt het zo instellen dat er wordt gecontroleerd of er iets is gewijzigd na een uur, een dag, enz.). Maar wat als er geen betrouwbare manier is om van tevoren te bepalen wanneer een bepaalde bron zal veranderen? Ik heb bijvoorbeeld geen idee of het een uur, een dag of een jaar zal duren voordat ik terugkom en iets in dit bericht bewerk – en waarom zou ik maar een uur cachen als cachen voor een dag ook prima zou zijn geweest?

Dit is waar de mogelijkheid om de cache handmatig te wissen (of door uw webapplicatie NGINX te laten melden dat er iets moet worden gewist) nodig is. De mensen achter NGINX zijn zich duidelijk bewust van de noodzaak hiervan, aangezien de functie wordt ondersteund in de betaalde versie van hun product – maar hoewel ze zeker het recht hebben om hun licentie op elke gewenste manier in te stellen, is de prijs voor mij een beetje hoog als deze functie de enige betaalde functie is die ik echt nodig heb.

Gelukkig blijkt dat je gewoon zelf bestanden uit de cachedirectory kunt verwijderen en NGINX zal dit opmerken en zonder problemen een nieuwe kopie van je back-end ophalen. Als je dit echter doet zonder je configuratie aan te passen, zul je na een tijdje waarschijnlijk een heleboel berichten zien die lijken op deze in je foutenlogboek:

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

Het lijkt erop dat deze fouten optreden wanneer NGINX zelf probeert cache-items te verwijderen na de tijd die is opgegeven door de inactive parameter van de fastcgi_cache_path directive. De standaard hiervoor is slechts 10 minuten, maar u kunt deze op elke gewenste waarde instellen. Als u deze bijvoorbeeld instelt op 10 jaar, is het waarschijnlijk onwaarschijnlijk dat u de server in de tussentijd niet opnieuw hebt opgestart, dus de sleutelindex in het geheugen zou in de tussentijd zijn gewist. Als u dit doet, moet u er dan voor zorgen dat u de cache zelf wist, NGINX zal dit niet meer voor u doen.

Ik vind het echt vreemd dat het als een kritieke fout wordt beschouwd dat een cache-item niet kan worden verwijderd omdat het niet bestaat. Het feit dat de ernstclassificatie zo hoog is, betekent dat het onmogelijk is om het te verwijderen door log-items onder een bepaalde drempel te negeren. Zodra er een nieuwe kopie van de back-end wordt opgehaald, bestaat het item weer, dus dit zou wat mij betreft hooguit een waarschuwing moeten zijn.

Als de cache-invoer niet kon worden verwijderd vanwege problemen met machtigingen of iets dergelijks, zou dat een kritieke fout zijn. Het kan er namelijk toe leiden dat NGINX gecachte inhoud blijft aanbieden lang nadat de cache is verlopen. Het opschoonproces lijkt hier echter geen onderscheid in te maken.