rsyslog avec logrotate: recharger rsyslog vs copytruncate

Je travaille sur Ubuntu 14 avec l'utilitaire rsyslog et logrotate par défaut.

Dans la /etc/logrotate.d/rsyslogconfiguration par défaut rsyslog logrotate, je vois ce qui suit:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

D'après ce que je comprends, il est recommandé d'utiliser copytruncate dans tous les scénarios logrotate, car il ne déplace pas le journal actuel, mais tronque plutôt le journal afin que tout processus avec un gestionnaire de fichiers ouvert puisse continuer à y écrire.

Alors, comment se fait-il que la configuration par défaut utilise la fonctionnalité de rechargement de rsyslog?

Pour répondre à votre question, vous devez d'abord comprendre les différents compromis entre recharger et copier-tronquer:

• recharger : l'ancien fichier journal est renommé et le processus qui écrit dans ce journal est averti (via le signal Unix) de recréer son fichier journal. C'est la méthode de surcharge la plus rapide / la plus faible: les opérations de renommage / déplacement sont très rapides et ont un temps d'exécution constant. De plus, il s'agit d'une opération presque atomique: cela signifie que (presque) aucune entrée de journal ne sera perdue pendant le déplacement / rechargement. D'un autre côté, vous avez besoin d' un processus capable de recharger et de rouvrir son fichier journal. Rsyslog est un tel processus, donc la configuration logrotate par défaut utilise la méthode de rechargement. L'utilisation de ce mode avec rsyslog est fortement recommandée par rsyslog en amont.
• copytruncate : l'ancien fichier journal est copié dans un fichier d'archive, puis il est tronqué pour "supprimer" les anciennes lignes de journal. Bien que l'opération tronquée soit très rapide, la copie peut être assez longue (selon la taille de votre fichier journal). De plus, certaines entrées de journal peuvent être perdues pendant le temps entre l'opération de copie (rappelez-vous, cela peut être lent) et la troncature. Pour ces raisons, copytruncate n'est pas utilisé par défaut pour les services capables de recharger et de recréer leurs fichiers journaux. D'un autre côté, si un serveur n'est pas capable de recharger / recréer des fichiers journaux, copytruncate est votre pari le plus sûr. En d'autres termes, il ne nécessite aucune prise en charge au niveau du service. Le projet amont rsyslog déconseille fortement d'utiliser ce mode.

Parlant en tant qu'auteur rsyslog, copytruncate est en fait un très, très, très mauvais choix. Il est intrinsèquement racé et son utilisation est presque une garantie que vous perdrez les données du journal. Plus le fichier est écrit fréquemment, plus vous en perdrez. Et cela ne fait pas seulement partie de la dernière ligne, mais peut être de plusieurs centaines, selon le moment exact et l'état du système au moment de la rotation.

Lorsque le fichier est déplacé et qu'un nouvel inode (fichier) est créé, rsyslog conserve la trace du fichier précédent et termine le traitement. Vous n'avez donc aucune perte dans ce cas. Garanti (sauf si vous démontez le système de fichiers ...).

Sur "reopenOnTruncate": J'ai personnellement vu reopenOnTruncate être aussi racé à d'autres égards, en particulier avec NFS et similaires. Il y a quelque temps, j'ai totalement supprimé cette fonctionnalité, mais j'ai été persuadé plus tard de fusionner des fonctionnalités similaires. Cela restera probablement "expérimental" pour toujours, car je sais vraiment que les gens ont des problèmes sur des systèmes très chargés. "copytruncate" n'est tout simplement pas un mode décent pour travailler avec des fichiers journaux.

Je travaille actuellement sur le refactoring imfile (ETA 8.34 ou 8.35). La version remaniée sera probablement en mesure d'empêcher un renvoi accidentel en raison de la course à l'API, mais ne peut pas non plus se prémunir contre la perte de données, car cela est conceptuellement impossible.

Cela dépend complètement de la façon dont le processus écrit les journaux.
copytruncatene fonctionne que si les messages du journal sont ajoutés au fichier (par exemple whatever >> logfile.
Et pas lorsqu'il redirige la sortie (par exemple whatever > logfile).

Depuis la version 8.16, rsyslog a une option imfile reopenOnTruncatequi gère le problème du copytruncte.

Pour rsyslog en particulier, il est probablement plus logique de laisser les choses telles quelles.

La raison fondamentale est que rsyslog a des files d'attente internes qu'il peut utiliser dans les cas où son descripteur de sortie devient indisponible.

Le rechargement a) entraînera rsyslog à recréer son propre fichier journal, et b) provoquera le vidage de tous les événements en file d'attente dans le fichier lors de la création.

Il se peut que la copie tronquée ne nuise pas (même si je crains que des lignes partiellement écrites soient tronquées), mais j'aurais tendance à penser que copier / supprimer / recharger est `` plus sûr '' du point de vue de l'intégrité.

Comme mentionné par @ faker , puisque rsyslog peut gérer la situation où son fichier devient indisponible, il n'y a pas de raison impérieuse d'utiliser copytruncate.

Et comme mentionné par @ SelivanovPavel , rsyslog nécessite en fait une configuration spécifique pour gérer correctement la copie tronquée.

Donc, si seulement parce que l'utilisation de l' reloadapproche nécessite moins d'écart par rapport à la configuration par défaut, je la garderais.