Logrotate : corriger l’erreur « line too long in state file /var/lib/logrotate/status »

Ce matin, j’ai reçu ce message d’erreur de mon serveur par email :

/etc/cron.daily/logrotate:
error: line 672139 too long in state file /var/lib/logrotate/status
error: could not read state file, will not attempt to write into it
run-parts: /etc/cron.daily/logrotate exited with return code 1Langage du code : JavaScript (javascript)

Sous GNU/Linux, logrotate gère la rotation des fichiers de logs. Il archive, compresse, supprime ou renouvelle les journaux afin d’éviter qu’un fichier comme access.log, error.log, mail.log ou syslog ne grossisse indéfiniment.

Lorsque logrotate échoue, les logs ne tournent plus correctement. Et, tôt ou tard, les fichiers explosent en taille. Sur un serveur web, mail ou applicatif, cela peut finir par remplir une partition. C’est rarement le genre de surprise qui améliore un lundi matin.

L’erreur line too long in state file indique généralement que le fichier d’état de logrotate est corrompu. Voici comment le diagnostiquer et le corriger proprement.

À quoi sert logrotate ?

logrotate automatise la rotation des journaux système. Il peut traiter les logs tous les jours, toutes les semaines, tous les mois, ou selon leur taille. Il peut aussi compresser les anciennes archives, supprimer les plus anciennes, créer un nouveau fichier vide, exécuter des scripts après rotation et envoyer certains logs par email.

La documentation Ubuntu-fr résume bien son rôle : logrotate limite la taille des fichiers journaux présents dans /var/log en effectuant une rotation et, si configuré, une compression. Voir la documentation Ubuntu-fr sur logrotate.

Sur Debian et Ubuntu, la configuration principale se trouve généralement ici :

/etc/logrotate.conf

Les configurations par service se trouvent souvent dans :

/etc/logrotate.d/

Chaque service peut donc avoir sa propre politique de rotation : Apache, nginx, MySQL, PHP-FPM, Postfix, Dovecot, Redis, Varnish, etc.

À quoi sert le fichier /var/lib/logrotate/status ?

Le fichier /var/lib/logrotate/status garde l’état des dernières rotations. Il indique à logrotate quand chaque fichier de log a été traité pour la dernière fois.

La page de manuel Debian précise que le fichier d’état par défaut est /var/lib/logrotate/status, et que l’option -s ou --state permet d’utiliser un autre fichier d’état. Voir la page de manuel Debian de logrotate.

Ce fichier ressemble généralement à ceci :

logrotate state -- version 2
"/var/log/nginx/access.log" 2026-5-11-0:0:0
"/var/log/nginx/error.log" 2026-5-11-0:0:0
"/var/log/syslog" 2026-5-11-0:0:0Langage du code : JavaScript (javascript)

Il ne devrait pas contenir des lignes interminables. S’il contient une ligne énorme, tronquée ou corrompue, logrotate peut refuser de le lire et abandonner l’opération.

Comprendre l’erreur “line too long in state file”

Le message suivant signifie que logrotate a trouvé une ligne anormalement longue dans son fichier d’état :

error: line 672139 too long in state file /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Il refuse ensuite d’écrire dans ce fichier pour éviter d’aggraver la corruption :

error: could not read state file, will not attempt to write into itLangage du code : HTTP (http)

Le projet logrotate a déjà documenté ce type de comportement dans ses tickets : lorsqu’une ligne du fichier d’état n’est pas terminée correctement ou dépasse ce que logrotate peut lire, l’outil échoue avec une erreur de ligne trop longue. Voir l’issue logrotate #78.

Les causes possibles :

• fichier status corrompu ;
• écriture interrompue ;
• exécution concurrente ou anormale ;
• chemin de log très étrange ou généré automatiquement ;
• ancien bug ou outil tiers ayant écrit dans le fichier ;
• partition pleine au moment de l’écriture ;
• erreur disque ou système de fichiers.

Le fichier d’état n’est pas un log métier précieux. Il sert surtout à savoir quand les fichiers ont tourné. On peut donc le reconstruire, mais mieux vaut le sauvegarder avant d’y toucher.

Étape 1 : vérifier l’état actuel de logrotate

Commencez par tester logrotate en mode debug. Ce mode n’applique aucune modification aux logs ni au fichier d’état. La page de manuel indique que -d active le mode debug et implique le mode verbeux. Voir la page de manuel logrotate.

sudo logrotate -d /etc/logrotate.conf

Si le fichier d’état est corrompu, vous devriez retrouver l’erreur :

error: line 672139 too long in state file /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Vérifiez aussi la taille du fichier d’état :

sudo ls -lh /var/lib/logrotate/status
sudo wc -l /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Un nombre de lignes extrêmement élevé peut indiquer un fichier qui a accumulé des entrées inutiles ou corrompues.

Étape 2 : sauvegarder le fichier status

Avant de supprimer ou modifier quoi que ce soit, faites une sauvegarde du fichier d’état :

sudo cp -a /var/lib/logrotate/status /var/lib/logrotate/status.bak.$(date +%F-%H%M%S)Langage du code : JavaScript (javascript)

Ce n’est pas obligatoire pour réparer, mais cela permet de revenir en arrière ou d’inspecter la ligne problématique plus tard.

On peut aussi regarder autour de la ligne indiquée par l’erreur. Si l’erreur mentionne la ligne 672139, utilisez :

sudo sed -n '672135,672145p' /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Si la ligne est vraiment énorme, sed peut produire une sortie indigeste. Dans ce cas, contentez-vous de sauvegarder, puis recréez le fichier.

Solution rapide : recréer le fichier d’état logrotate

La solution la plus simple consiste à déplacer l’ancien fichier d’état, puis à laisser logrotate en recréer un propre.

Je préfère déplacer le fichier plutôt que le supprimer directement :

sudo mv /var/lib/logrotate/status /var/lib/logrotate/status.corrupt.$(date +%F-%H%M%S)Langage du code : JavaScript (javascript)

Ensuite, lancez un test en mode debug :

sudo logrotate -d /etc/logrotate.conf

Si le debug ne renvoie plus l’erreur, vous pouvez lancer une rotation réelle.

Pour forcer une rotation complète :

sudo logrotate -f /etc/logrotate.conf

L’option -f force la rotation même si logrotate estime qu’elle n’est pas nécessaire. C’est utile après la suppression manuelle d’anciens logs ou après la reconstruction du fichier d’état. La page de manuel décrit justement --force comme une façon de forcer la rotation. Voir la page de manuel logrotate sur man7.org.

Enfin, vérifiez que le fichier d’état a bien été recréé :

sudo ls -lh /var/lib/logrotate/status
sudo head /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Méthode alternative : supprimer uniquement la ligne corrompue

Si vous voulez conserver l’historique de rotation existant, vous pouvez supprimer uniquement la ligne indiquée par l’erreur.

Par exemple, pour supprimer la ligne 672139 après sauvegarde :

sudo cp -a /var/lib/logrotate/status /var/lib/logrotate/status.bak.$(date +%F-%H%M%S)
sudo sed -i '672139d' /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Puis testez :

sudo logrotate -d /etc/logrotate.conf

Si une autre ligne corrompue apparaît, le fichier est probablement trop abîmé. Dans ce cas, recréez-le entièrement.

Cette méthode est plus chirurgicale, mais moins nécessaire dans la plupart des cas. Le fichier status n’est pas une base de données critique. Il contient surtout les dates des dernières rotations.

Pourquoi éviter rm -rf ici ?

L’ancienne solution rapide consistait à faire :

rm -rf /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Techniquement, cela peut fonctionner. Mais rm -rf est inutilement violent pour supprimer un simple fichier.

Préférez :

sudo rm /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Ou, mieux encore, déplacez-le :

sudo mv /var/lib/logrotate/status /var/lib/logrotate/status.corrupt.$(date +%F-%H%M%S)Langage du code : JavaScript (javascript)

Déplacer le fichier est plus propre : on corrige le problème sans jeter la preuve du crime. Même en sysadmin, garder une scène de crime lisible aide parfois.

Vérifier les droits du fichier d’état

Après recréation, vérifiez les droits :

sudo ls -l /var/lib/logrotate/status
sudo ls -ld /var/lib/logrotateLangage du code : JavaScript (javascript)

Sur Debian/Ubuntu, le fichier appartient généralement à root. Si vous avez modifié les permissions par erreur, corrigez-les :

sudo chown root:root /var/lib/logrotate/status
sudo chmod 0644 /var/lib/logrotate/statusLangage du code : JavaScript (javascript)

Le dossier, lui, doit aussi rester propre :

sudo chown root:root /var/lib/logrotate
sudo chmod 0755 /var/lib/logrotateLangage du code : JavaScript (javascript)

Vérifier les configurations logrotate

Une fois le fichier d’état réparé, profitez-en pour vérifier la configuration. Une erreur dans /etc/logrotate.d/ peut empêcher certaines rotations ou générer des comportements étranges.

Lancez le mode debug :

sudo logrotate -d /etc/logrotate.conf

Pour obtenir plus de détails lors d’une exécution réelle :

sudo logrotate -v /etc/logrotate.conf

Et pour forcer une rotation après correction :

sudo logrotate -f -v /etc/logrotate.conf

Attention : -f force vraiment la rotation. Ne l’utilisez pas en boucle pour “tester”, sauf si vous aimez générer des archives de logs comme d’autres collectionnent les timbres.

Vérifier le service systemd ou cron

Sur les systèmes modernes, logrotate peut être lancé par cron ou par un timer systemd selon la distribution et la version.

Pour vérifier le timer systemd :

systemctl list-timers | grep -i logrotateLangage du code : PHP (php)

Pour vérifier l’état du service :

systemctl status logrotate --no-pager

Pour lire les derniers logs systemd liés à logrotate :

journalctl -u logrotate --no-pager -n 100

Si votre système utilise encore cron, regardez plutôt :

ls -l /etc/cron.daily/logrotate
grep -R logrotate /etc/cron* /var/spool/cron 2>/dev/nullLangage du code : JavaScript (javascript)

L’objectif est simple : confirmer que logrotate repassera bien automatiquement après la correction.

Surveiller les gros fichiers de logs

Si logrotate était bloqué depuis plusieurs jours ou semaines, certains logs peuvent déjà avoir grossi.

Pour lister les plus gros fichiers dans /var/log :

sudo find /var/log -type f -printf '%s %p\n' | sort -nr | head -20Langage du code : JavaScript (javascript)

Version plus lisible avec du :

sudo du -ah /var/log | sort -h | tail -30Langage du code : JavaScript (javascript)

Vérifiez aussi l’espace disque disponible :

df -h
df -ih

df -h vérifie l’espace disque. df -ih vérifie les inodes. Un serveur peut manquer d’inodes même s’il lui reste de l’espace disque. Oui, Linux a plusieurs manières de vous gâcher un café.

Cas Varnish : éviter les logs inutiles

L’article original mentionnait Varnish. Si vous utilisez Varnish, vérifiez bien quels logs vous conservez.

Varnish peut générer beaucoup de données, surtout si vous loguez des ressources statiques, des hits cache ou des requêtes très fréquentes. Selon votre usage, il peut être inutile d’encombrer le serveur avec des logs très verbeux sur des assets statiques.

Plutôt que de commenter aveuglément toute la configuration Varnish dans /etc/logrotate.conf, vérifiez d’abord où se trouve la configuration :

grep -R "varnish" /etc/logrotate.conf /etc/logrotate.d/Langage du code : JavaScript (javascript)

Ensuite, ajustez la politique de rotation ou réduisez ce que vous loguez réellement côté Varnish. La meilleure rotation reste parfois celle d’un log qu’on n’écrit pas.

Solution complète recommandée

Voici la séquence que je recommande sur un serveur Debian ou Ubuntu :

sudo logrotate -d /etc/logrotate.conf

sudo cp -a /var/lib/logrotate/status /var/lib/logrotate/status.bak.$(date +%F-%H%M%S)
sudo mv /var/lib/logrotate/status /var/lib/logrotate/status.corrupt.$(date +%F-%H%M%S)

sudo logrotate -d /etc/logrotate.conf
sudo logrotate -f -v /etc/logrotate.conf

sudo ls -lh /var/lib/logrotate/status
sudo systemctl list-timers | grep -i logrotate || trueLangage du code : JavaScript (javascript)

Cette méthode sauvegarde le fichier corrompu, teste avant modification réelle, force une rotation après correction, puis vérifie que le fichier d’état a été recréé.

Résumé rapide

Pour corriger rapidement :

sudo mv /var/lib/logrotate/status /var/lib/logrotate/status.corrupt.$(date +%F-%H%M%S)
sudo logrotate -d /etc/logrotate.conf
sudo logrotate -f /etc/logrotate.confLangage du code : JavaScript (javascript)

Si vous voulez supprimer plutôt que déplacer :

sudo rm /var/lib/logrotate/status
sudo logrotate -f /etc/logrotate.confLangage du code : JavaScript (javascript)

Mais, franchement, déplacer le fichier reste plus propre.

Conclusion

L’erreur line too long in state file /var/lib/logrotate/status indique que le fichier d’état de logrotate est corrompu ou illisible.

Comme ce fichier sert surtout à mémoriser la dernière rotation des logs, on peut le recréer sans drame. Le plus propre consiste à le sauvegarder ou le déplacer, tester avec logrotate -d, puis forcer une rotation avec logrotate -f.

Une fois la rotation relancée, vérifiez les gros fichiers dans /var/log et assurez-vous que le timer systemd ou la tâche cron fonctionne encore.

Ce n’est pas une panne spectaculaire, mais elle mérite d’être corrigée rapidement. Les logs qui ne tournent plus ont une fâcheuse tendance à manger le disque en silence.

Sources utiles

• man7.org : page de manuel logrotate
• Debian manpages : logrotate et fichier d’état
• linux.die.net : options debug et force de logrotate
• Ubuntu-fr : documentation logrotate
• GitHub logrotate : erreur “line too long in state file”

Report a typo