Rotera en VPN-watchdog-logg utan att bryta skrivaren

En VPN-hälsokontroll som lägger till en rad i minuten skapar tyst en andra plikt: att bestämma hur dessa rader lämnar disken. Att reparera tunneln gör ingenting för den plikten, och att byta namn på filen omdirigerar inte en process som fortfarande håller den gamla deskriptorn. Svara först på frågan om mottagaren och anpassa sedan rotationen till hur skrivaren öppnar den.

Välj mottagaren före rotationspolicyn

En systemd-enhet som redan skickar sin utdata till journalen håller kvarhållningen på ett ställe. journald framtvingar gränser som SystemMaxUse och MaxRetentionSec , så en watchdog som loggar där ärver en gräns utan extra arbete. Att lägga till en andra obegränsad fil bredvid den fördubblar underhållet utan vinst.

En dedikerad fil förtjänar sin plats när något annat läser den: en parser, en revisionsexport eller en sida som förväntar sig en stabil sökväg. När det beslutet är fattat behöver filen en ägare, ett läge och en rotationspolicy skrivna tillsammans, eftersom de tre bara är korrekta som en uppsättning. En sökväg som vem som helst kan skapa är också en sökväg som vem som helst kan ersätta, så katalogbehörigheterna hör hemma i samma anteckning. Skriv allt detta bredvid kontrollen och nästa ändring börjar från samma fakta.

Skriv blocket så att det passar skrivaren

Börja med en skrivare som öppnar sökvägen vid varje anrop, lägger till en rad och avslutar. Det mönstret överlever rotation utan något samarbete från processen, eftersom nästa körning öppnar den fil som just nu ligger på den sökvägen. Blocket nedan behåller en veckas versioner och återskapar filen med den ägare och det läge som skrivaren behöver:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

logrotate-handboken definierar antalet som antalet behållna roterade versioner, inte som en garanti för sju dagars historik, och nyckelordet daily utvärderas när jobbet körs i stället för att fungera som sin egen schemaläggare. På de flesta distributioner äger en systemd-timer eller en cron-post redan det anropet, så kontrollera vilken som finns innan du lägger till en andra. Att få ägarskapet att stämma är viktigare än antalet. Att kopiera ett läge endast för root till en fil som skrivs av ett tjänstekonto stoppar loggningen vid nästa rotation, och felet visas timmar senare som en inaktuell tidsstämpel i stället för som ett fel. Bekräfta skrivarens användare innan du kopierar ett block från någon annanstans.

En skrivare som aldrig öppnar igen behöver en annan lösning

En långvarig process som håller en öppen deskriptor fortsätter skriva till den omdöpta inoden. Utrymme frigörs inte och den synliga filen slutar växa, vilket ser ut som en trasig rotation tills du kontrollerar inoden. Antingen lär du processen att öppna igen, eller låter du rotationen kopiera och korta av i stället för att byta namn.

Vägen med att öppna igen är den renaste där programvaran stöder det: skicka den dokumenterade signalen eller kör det dokumenterade kommandot, och låt processen öppna den nya filen själv. Alternativet är copytruncate , som kopierar innehållet till det roterade namnet och sedan kortar av originalet på plats, så deskriptorn förblir giltig men skrivningar som faller mellan kopian och avkortningen går förlorade.

För enheter som startas av systemd, rikta StandardOutput mot journalen eller mot en fil och låt enheten äga livscykeln. En shell-loop som lägger till via tee -a utan storleksgräns är det arrangemang som fyller en partition under ett avbrott, eftersom en misslyckad kontroll ofta loggar mycket mer än en frisk.

Testa rotationen utan att vänta på timern

Felsökningsläget rapporterar vad som skulle hända och rör ingenting, vilket gör det till den säkra första körningen efter en ändring. Tvinga fram en riktig rotation när du är nöjd och bekräfta sedan att nästa loggrad landar i den nya filen i stället för den omdöpta:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Läs utdata i den ordningen. Felsökningspasset ska namnge filen och de åtgärder det avser; en påtvingad körning ska producera det roterade namn du förväntade dig; tail ska visa en färsk post efter att skrivaren körs igen. Ett växande df-värde med en krympande synlig fil betyder deskriptorproblemet som beskrivs ovan.

Upprepa den påtvingade körningen två gånger för att se hur kvarhållningen beter sig när versioner redan finns. Att radera den äldsta filen är det förväntade resultatet, och en utebliven radering betyder vanligtvis att antalet eller jokertecknet i det roterade namnet inte matchar det logrotate skapade.

Behåll en återställning och en skriftlig dokumentation

Spara föregående block innan du redigerar och notera vilken schemaläggare som kör det, eftersom en återställning som återställer filen men inte timern återskapar halva det ursprungliga problemet. Rotera en gång för hand efter återställningen och bekräfta sedan att skrivarens konto kan skriva på loggsökvägen. Om tjänsten körs under systemd, ladda om enheten efter varje ändring av dess utdataomdirigering, eftersom den körande processen fortsätter skriva till det gamla målet. Läs de nästa loggraderna själv i stället för att lita på att enheten kom tillbaka rent.

Anteckna läget, ägaren, antalet kvarhållningar och den förväntade diskbudgeten bredvid själva kontrollen. När kontrollen senare ändras från ett engångsskript till en daemon måste rotationspolicyn ändras med den, och den anteckningen talar om för nästa person vilket antagande som brast.

Slutligen, håll loggbeslutet åtskilt från återställningsbeslutet. En misslyckad kontroll bör följa anslutningens egen återställningspolicy, inte en regel som gömts i logrotate, och inget loggarrangemang bör vara anledningen till att en fungerande tunnel startas om.