Project

General

Profile

Tâche #33970

Scénario #33848: Pb logrotate winbindd

Étude du problème

Added by Benjamin Bohard about 2 years ago. Updated about 2 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Start date:
03/28/2022
Due date:
% Done:

100%

Remaining (hours):
0.0

Description

Le rapport de l’utilisateur fait émerger deux problèmes : un problème de rotation et un problème de compression.
La résolution devrait résoudre ces deux problèmes.

eole-purge-logs (1.69 KB) Benjamin Bohard, 03/30/2022 04:17 PM

History

#1 Updated by Benjamin Bohard about 2 years ago

  • Status changed from Nouveau to En cours

#2 Updated by Benjamin Bohard about 2 years ago

Le problème de rotation est suggéré par le suffixe de date ajouté plusieurs fois au même fichier.
Le problème de compression serait, lui, lié à la longueur du chemin des fichiers (augmentée par les suffixes multiples).

Lors de la réunion, il a été remarqué que les journaux concernés sont de taille nulle.
L’hypothèse d’une coopération problématique entre les options notifempty et delaycompress a été avancée : il y aurait une rotation (ajout du suffixe) des fichiers mais pas de compression.

Quelques tests ont été effectués pour vérifier cette hypothèse qui, si elle est vérifiée, impliquerait la révision du fichier de configuration de logrotate pour les journaux de winbind (fournie par le paquet samba).

Test 1

Soit un serveur dc1 2.8.1 :
- log.winbindd vide
- fichier /var/log/samba/log.winbindd-29220327 vidé (truncate -s0, le fichier est issu d’une rotation normale du précédent fichier /var/log/samba/log.winbindd qui n’était pas vide).

Après une rotation (forcée et programmée), le phénomène de suffixe multiple n’est pas observé (et le fichier issu de la rotation et vidé n’est pas compressé)

Test 2 (cas "normal")

Sur le même serveur :
- /var/log/samba/log.winbindd non vide (pour que la rotation soit bien déclenchée)
- fichier /var/log/samba/log.winbindd-29220327 avec du contenu.

Après rotation forcée, comportement attendu :
- rotation du fichier log.winbindd vers log.winbindd-20220329
- compression du fichier log.winbindd-20220327.

Test 3

Sur le même serveur:
- fichier log.winbindd-20220329 tronqué et renommé en log.winbindd-20220328
- ajout de contenu au fichier log.winbindd (pour que la rotation soit bien déclenchée)

La rotation forcée donne le résultat attendu :
- l’ancien fichier log.winbindd a bien subi la rotation vers log.winbindd-20220329
- log.winbindd-20220328 a été compressé
- nouveau fichier log.winbindd vide.

Test 4

Sur le même serveur :
- ajout de contenu à log.winbindd
- troncature de log.winbindd-20220329 mais pas de renommage.

La rotation forcée ne fait pas la rotation du fichier log.winbindd (error: destination /var/log/samba/log.winbindd-20220329 already exists, skipping rotation) mais le fichier log.winbindd-20220329 est bien compressé (pas de suffixe ajouté).

La configuration en place

Sur un module Seth 2.8.1, la règle de rotation pour winbind est la suivante :

/var/log/samba/log.winbindd {
    weekly
    missingok
    rotate 7
    postrotate
        if [ -x /usr/bin/smbcontrol ]; then
            /usr/bin/smbcontrol winbindd reload-config
        elif [ -f /run/samba/winbindd.pid ]; then
            kill -HUP `cat /run/samba/winbindd.pid`
        fi
    endscript
    compress
    delaycompress
    notifempty
}

#3 Updated by Benjamin Bohard about 2 years ago

Même constat effectué sur une 2.7.2. À ce stade, la raison de la création des fichiers avec les noms à rallonge reste inexpliquée.

À défaut de pouvoir prévenir ce genre de situation, on peut mettre en place une opération de nettoyage qui supprime les fichiers vide avec ce type de nom.

#4 Updated by Benjamin Bohard about 2 years ago

Quelques observations sur ce qui apparaît dans la liste des fichiers fournie :
- les noms à rallonge ne sont pas exclusivement liés à des fichiers vides
- les fichiers vides avec nom à rallonge ont été modifiés soit le 2022-02-06 06:25, soit le 2022-02-13 06:25 et les timestamps les plus anciens sont du 20210912 (problème passager et terminé ?)
- les dates des timestamps et du système de fichier du seul fichier non vide avec nom à rallonge ne correspondent pas

Pour le nettoyage, sans connaissance des causes de la création des fichiers, les éléments sont faibles pour discriminer les fichiers à supprimer. Étant donné que la rotation admet des absences de fichiers, on doit pouvoir supprimer tous les fichiers vides. Pour le fichier non vide, ne pouvant juger du contenu, il serait peut-être préférable de le renommer, par exemple en tronquant le nom de fichier au premier timestamp si ce nom est unique.

Par rapport à la problématique de la compression, selon les tests menés, logrotate ne prend pas en compte les fichiers dans le nom s’écartent du schéma <nom>-<timestamp> dans le cadre d’une compression différée ni les fichiers renommés dont le timestamp s’insère entre ceux de fichiers compressés.

#5 Updated by Benjamin Bohard about 2 years ago

#6 Updated by Benjamin Bohard about 2 years ago

  • Status changed from En cours to À valider

#7 Updated by Ludwig Seys about 2 years ago

  • Status changed from À valider to Résolu

#8 Updated by Joël Cuissinat about 2 years ago

  • Status changed from Résolu to Fermé
  • % Done changed from 0 to 100
  • Remaining (hours) set to 0.0

Also available in: Atom PDF