Faire tourner un journal de chien de garde VPN sans casser l’écrivain

Un contrôle de santé VPN qui ajoute une ligne par minute crée discrètement un second devoir : décider comment ces lignes quittent le disque. Réparer le tunnel ne fait rien pour ce devoir, et renommer le fichier ne redirige pas un processus qui détient encore l’ancien descripteur. Répondez d’abord à la question de la destination, puis faites correspondre la rotation à la façon dont l’écrivain l’ouvre.

Choisissez la destination avant la politique de rotation

Une unité systemd qui envoie déjà sa sortie au journal garde la rétention à un seul endroit. journald applique des limites comme SystemMaxUse et MaxRetentionSec , donc un chien de garde qui journalise là hérite d’une borne sans travail supplémentaire. Ajouter un second fichier sans limite à côté double la maintenance sans gain.

Un fichier dédié mérite sa place quand autre chose le lit : un analyseur, un export d’audit ou une page qui attend un chemin stable. Une fois cette décision prise, le fichier a besoin d’un propriétaire, d’un mode et d’une politique de rotation écrits ensemble, car les trois ne sont corrects qu’en tant qu’ensemble. Un chemin que n’importe qui peut créer est aussi un chemin que n’importe qui peut remplacer, donc les permissions du répertoire appartiennent à la même note. Écrivez tout cela à côté du contrôle et la prochaine modification partira des mêmes faits.

Écrivez le bloc pour correspondre à l’écrivain

Partez d’un écrivain qui ouvre le chemin à chaque invocation, ajoute une ligne et sort. Ce modèle survit à la rotation sans aucune coopération du processus, car l’exécution suivante ouvre le fichier qui se trouve actuellement à ce chemin. Le bloc ci-dessous conserve une semaine de versions et recrée le fichier avec le propriétaire et le mode dont l’écrivain a besoin :

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

Le manuel de logrotate définit le compte comme le nombre de versions rotationnées conservées, non comme une garantie de sept jours d’historique, et le mot-clé daily est évalué à l’exécution de la tâche au lieu d’agir comme son propre planificateur. Sur la plupart des distributions, un minuteur systemd ou une entrée cron possède déjà cette invocation, alors vérifiez lequel existe avant d’en ajouter un second. Faire correspondre la propriété compte plus que le nombre de rétentions. Copier un mode réservé à root sur un fichier écrit par un compte de service arrête la journalisation à la rotation suivante, et la panne apparaît des heures plus tard comme un horodatage périmé plutôt que comme une erreur. Confirmez l’utilisateur de l’écrivain avant de copier un bloc d’ailleurs.

Un écrivain qui ne rouvre jamais a besoin d’un autre remède

Un processus de longue durée qui détient un descripteur ouvert continue d’écrire dans l’inode renommé. L’espace n’est pas libéré et le fichier visible cesse de croître, ce qui ressemble à une rotation cassée jusqu’à ce que vous vérifiiez l’inode. Soit apprenez au processus à rouvrir, soit faites en sorte que la rotation copie et tronque au lieu de renommer.

La voie de la réouverture est la plus propre là où le logiciel la prend en charge : envoyez le signal documenté ou exécutez la commande documentée, et laissez le processus ouvrir lui-même le nouveau fichier. L’alternative est copytruncate , qui copie le contenu vers le nom rotationné puis tronque l’original sur place, de sorte que le descripteur reste valide mais les écritures qui tombent entre la copie et la troncature sont perdues.

Pour les unités lancées par systemd, pointez StandardOutput vers le journal ou vers un fichier et laissez l’unité posséder le cycle de vie. Une boucle shell qui ajoute via tee -a sans limite de taille est la disposition qui remplit une partition pendant une panne, car un contrôle en échec journalise souvent bien plus qu’un contrôle sain.

Testez la rotation sans attendre le minuteur

Le mode débogage indique ce qui se passerait et ne touche à rien, ce qui en fait la première exécution sûre après une modification. Forcez une vraie rotation lorsque vous êtes satisfait, puis confirmez que la ligne de journal suivante atterrit dans le nouveau fichier plutôt que dans le renommé :

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

Lisez la sortie dans cet ordre. La passe de débogage devrait nommer le fichier et les actions qu’elle prévoit ; une exécution forcée devrait produire le nom rotationné attendu ; la queue devrait montrer une entrée fraîche après que l’écrivain a tourné à nouveau. Une valeur df croissante avec un fichier visible qui rétrécit signifie le problème de descripteur décrit plus haut.

Répétez l’exécution forcée deux fois pour voir comment la rétention se comporte lorsque des versions existent déjà. Supprimer le fichier le plus ancien est le résultat attendu, et une suppression absente signifie généralement que le compte ou le joker du nom rotationné ne correspond pas à ce que logrotate a créé.

Gardez un retour arrière et une trace écrite

Enregistrez le bloc précédent avant de modifier et notez quel planificateur l’exécute, car un retour arrière qui restaure le fichier mais pas le minuteur reproduit la moitié du problème initial. Effectuez une rotation manuelle après la restauration, puis confirmez que le compte de l’écrivain peut écrire sur le chemin du journal. Si le service tourne sous systemd, rechargez l’unité après tout changement de redirection de sa sortie, car le processus en cours continue d’écrire vers l’ancienne cible. Lisez vous-même les quelques lignes de journal suivantes au lieu de croire que l’unité est revenue proprement.

Notez le mode, le propriétaire, le nombre de rétentions et le budget disque attendu à côté du contrôle lui-même. Lorsque le contrôle passera plus tard d’un script ponctuel à un démon, la politique de rotation devra changer avec lui, et cette note est ce qui indique à la personne suivante quelle hypothèse a cassé.

Enfin, gardez la décision de journalisation séparée de la décision de récupération. Un contrôle échoué doit suivre la politique de récupération propre à la connexion, non une règle cachée dans logrotate, et aucune disposition de journalisation ne devrait être la raison de redémarrer un tunnel qui fonctionne.