Die verwydering van NGINX-kas plaas kritieke ontkoppelingsfoute in die foutlogboek

Die inligting in hierdie pos is gebaseer op FastCGI-kas op NGINX 1.4.6 wat op Ubuntu Server 14.04 x64 loop. Dit mag al dan nie geldig wees vir ander weergawes nie.

(Opdatering 2025: In die tyd tussen ek die oorspronklike plasing geskryf het en nou, het baie verander. Bedieners is vinniger en goedkoper, so ek sal eintlik nie die benadering aanbeveel wat in hierdie pos beskryf word nie, waar ek probeer om die verstryking van die kas te mikrobestuur net om 'n paar ekstra generasies dinamiese inhoud te bespaar. Ek sal die inhoud hier laat vir toekomstige verwysing en ingeval iemand dit om watter rede ook al nodig het. Ek het egter nie bevestig dat dit nog steeds vir huidige weergawes van NGINX werk nie, maar ek sou dink dat dit wel werk).

Nadat ek verskeie webwerwe van Apache na NGINX gemigreer het, het ek baie lief geword vir sy ingeboude kasvermoëns, wat onder die meeste omstandighede baie goed werk sonder veel inmenging van my.

Vir een van die webwerwe het ek egter regtig die vermoë nodig gehad om die kas self skoon te maak (beide volledig en individuele inskrywings te verwyder). Die gratis gemeenskapsuitgawe van NGINX ondersteun slegs tydgebaseerde kasverstryking (dws jy kan dit opstel om te kyk of iets na 'n uur, 'n dag, ens.) verander het. Maar wat as daar geen betroubare manier is om voor die tyd te bepaal wanneer 'n sekere hulpbron sal verander nie? Ek het byvoorbeeld geen idee of dit 'n uur, 'n dag of 'n jaar sal duur voordat ek terugkom en iets in hierdie pos wysig nie - en hoekom net vir 'n uur kas as kas vir 'n dag goed sou gewees het?

Dit is waar die vermoë nodig is om die kas handmatig skoon te maak (of deur NGINX in kennis te stel dat iets skoongemaak moet word). Die mense agter NGINX is duidelik bewus van die behoefte hieraan, aangesien die funksie in die betaalde weergawe van hul produk ondersteun word - maar hoewel hulle beslis geregtig is om hul lisensiëring op te stel soos hulle wil, is die prys vir my 'n bietjie steil as hierdie funksie die enigste betaalde funksie is wat ek regtig nodig het.

Gelukkig blyk dit dat jy net self lêers uit die kasgids kan uitvee en NGINX sal dit optel en 'n nuwe kopie sonder probleme van jou back-end gaan haal. As jy dit egter doen sonder om jou konfigurasie aan te pas, sal jy waarskynlik na 'n rukkie 'n hele klomp boodskappe soortgelyk aan hierdie een in jou foutlogboek sien:

Dit blyk dat hierdie foute voorkom wanneer NGINX self probeer om kasinskrywings uit te vee na die tyd wat deur die onaktiewe parameter van die fastcgi_cache_path-richtlijn gespesifiseer word. Die standaard hiervoor is slegs 10 minute, maar jy kan dit stel op watter waarde jy wil. As jy dit op byvoorbeeld 10 jaar stel, is dit waarskynlik onwaarskynlik dat jy nie die bediener intussen herbegin het nie, sodat die sleutelindeks in die geheue intussen skoongemaak sou gewees het. As jy dit doen, moet jy seker maak dat jy self die kas skoonmaak, NGINX sal dit nie meer vir jou doen nie.

Ek vind dit regtig vreemd dat dit as 'n kritieke fout beskou word dat 'n kasinskrywing nie uitgevee kan word nie omdat dit nie bestaan nie. Die feit dat die ernsklassifikasie daarvan so hoog is, beteken dat dit onmoontlik is om van ontslae te raak net deur loginskrywings onder 'n sekere drempel te ignoreer. Sodra 'n nuwe kopie van die agterkant af gehaal word, sal die inskrywing weer bestaan, so dit behoort na my mening hoogstens 'n waarskuwing te wees.

Nou, as die kasinskrywing nie uitgevee kon word nie weens probleme met toestemmings of iets derde, sou dit 'n kritieke fout wees, want dit kan NGINX laat voortgaan om kasinhoud lank na die vervaldatum te bedien, maar dit lyk asof die skoonmaakproses nie hierdie onderskeid tref nie.