Ruotare un registro del watchdog VPN senza rompere lo scrittore

Un controllo di salute VPN che aggiunge una riga al minuto crea silenziosamente un secondo dovere: decidere come quelle righe lasciano il disco. Riparare il tunnel non fa nulla per quel dovere, e rinominare il file non reindirizza un processo che tiene ancora il vecchio descrittore. Rispondete prima alla domanda sulla destinazione, poi fate corrispondere la rotazione al modo in cui lo scrittore lo apre.

Scegliete la destinazione prima della politica di rotazione

Un’unità systemd che invia già il proprio output al journal mantiene la conservazione in un solo posto. journald applica limiti come SystemMaxUse e MaxRetentionSec , quindi un watchdog che registra lì eredita un limite senza lavoro extra. Aggiungere un secondo file senza limiti accanto raddoppia la manutenzione senza alcun guadagno.

Un file dedicato guadagna il suo posto quando qualcos’altro lo legge: un parser, un’esportazione di audit o una pagina che si aspetta un percorso stabile. Una volta presa quella decisione, il file ha bisogno di un proprietario, di un modo e di una politica di rotazione scritti insieme, perché i tre sono corretti solo come insieme. Un percorso che chiunque può creare è anche un percorso che chiunque può sostituire, quindi i permessi della directory appartengono alla stessa nota. Scrivete tutto accanto al controllo e la prossima modifica partirà dagli stessi fatti.

Scrivete il blocco in modo che corrisponda allo scrittore

Partite da uno scrittore che apre il percorso a ogni invocazione, aggiunge una riga ed esce. Quello schema sopravvive alla rotazione senza alcuna cooperazione del processo, perché l’esecuzione successiva apre il file che ora si trova su quel percorso. Il blocco sotto conserva una settimana di versioni e ricrea il file con il proprietario e il modo di cui lo scrittore ha bisogno:

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

Il manuale di logrotate definisce il conteggio come il numero di versioni ruotate conservate, non come una garanzia di sette giorni di cronologia, e la parola chiave daily viene valutata quando il lavoro viene eseguito invece di agire come pianificatore autonomo. Sulla maggior parte delle distribuzioni un timer systemd o una voce cron possiede già quell’invocazione, quindi verificate quale esiste prima di aggiungerne una seconda. Far corrispondere la proprietà conta più del numero di conservazione. Copiare un modo riservato a root su un file scritto da un account di servizio interrompe la registrazione alla rotazione successiva, e il guasto appare ore dopo come un timestamp obsoleto anziché come un errore. Confermate l’utente dello scrittore prima di copiare un blocco da altrove.

Uno scrittore che non riapre mai ha bisogno di un’altra soluzione

Un processo di lunga durata che tiene un descrittore aperto continua a scrivere nell’inode rinominato. Lo spazio non viene liberato e il file visibile smette di crescere, il che sembra una rotazione rotta finché non controllate l’inode. O insegnate al processo a riaprire, oppure fate in modo che la rotazione copi e tronchi invece di rinominare.

Il percorso di riapertura è il più pulito dove il software lo supporta: inviate il segnale documentato o eseguite il comando documentato, e lasciate che il processo apra da solo il nuovo file. L’alternativa è copytruncate , che copia il contenuto nel nome ruotato e poi tronca l’originale sul posto, così il descrittore resta valido ma le scritture che cadono tra la copia e il troncamento vanno perse.

Per le unità avviate da systemd, puntate StandardOutput al journal o a un file e lasciate che l’unità possieda il ciclo di vita. Un ciclo shell che aggiunge tramite tee -a senza limite di dimensione è la disposizione che riempie una partizione durante un’interruzione, perché un controllo fallito registra spesso molto più di uno sano.

Provate la rotazione senza aspettare il timer

La modalità di debug riporta cosa accadrebbe e non tocca nulla, il che la rende la prima esecuzione sicura dopo una modifica. Forzate una rotazione reale quando siete soddisfatti, poi confermate che la riga di log successiva finisca nel nuovo file anziché in quello rinominato:

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

Leggete l’output in quell’ordine. La passata di debug dovrebbe nominare il file e le azioni che intende; un’esecuzione forzata dovrebbe produrre il nome ruotato atteso; la coda dovrebbe mostrare una voce nuova dopo che lo scrittore viene eseguito di nuovo. Un valore df crescente con un file visibile che si restringe significa il problema di descrittore descritto sopra.

Ripetete l’esecuzione forzata due volte per vedere come si comporta la conservazione quando esistono già delle versioni. Eliminare il file più vecchio è il risultato atteso, e un’eliminazione mancante di solito significa che il conteggio o il carattere jolly nel nome ruotato non corrispondono a ciò che logrotate ha creato.

Mantenete un ripristino e una traccia scritta

Salvate il blocco precedente prima di modificare e annotate quale pianificatore lo esegue, perché un ripristino che riporta il file ma non il timer riproduce metà del problema originale. Ruotate una volta a mano dopo il ripristino, poi confermate che l’account dello scrittore possa scrivere sul percorso del log. Se il servizio gira sotto systemd, ricaricate l’unità dopo ogni modifica alla redirezione del suo output, perché il processo in esecuzione continua a scrivere sul vecchio obiettivo. Leggete voi stessi le righe di log successive invece di fidarvi che l’unità sia tornata pulita.

Registrate il modo, il proprietario, il conteggio di conservazione e il budget disco atteso accanto al controllo stesso. Quando in seguito il controllo passerà da uno script una tantum a un demone, la politica di rotazione dovrà cambiare con esso, e quella nota è ciò che dice alla persona successiva quale ipotesi si è rotta.

Infine, tenete la decisione sul log separata dalla decisione di recupero. Un controllo fallito dovrebbe seguire la politica di recupero della connessione stessa, non una regola nascosta dentro logrotate, e nessuna disposizione di registrazione dovrebbe essere la ragione per riavviare un tunnel che funziona.