Observer un fichier avec inotifywait pour confirmer l’écriture d’un service

Un service semble tourner, mais le fichier attendu reste vide. Avant de modifier sa configuration ou de fouiller des centaines de lignes dans journalctl, observez directement le répertoire où il doit écrire.

inotifywait affiche les créations, modifications et déplacements vus par le noyau. Vous pourrez confirmer une écriture limitée, puis savoir quand cet outil ne suffit plus.

Identifier le chemin avant de lancer la surveillance

Commencez par le chemin absolu. Un service systemd peut écrire dans /var/log/nom-service, dans un répertoire applicatif ou uniquement dans le journal système. Sur Debian et Ubuntu, vérifiez d’abord l’unité et ses journaux :

sudo systemctl status mon-service --no-pager
sudo journalctl -u mon-service -n 50 --no-pager

Si vous avez déjà un fichier précis, contrôlez son propriétaire, ses droits et l’espace disponible. Une surveillance ne corrige ni un répertoire absent ni un disque plein.

sudo ls -ld /var/log/mon-service
sudo df -h /var/log/mon-service

Installez ensuite inotify-tools si la commande manque. Le paquet porte ce nom sur Debian et Ubuntu.

sudo apt update
sudo apt install inotify-tools

Sur une machine RHEL, Fedora ou Rocky, le paquet s’appelle aussi généralement inotify-tools. Vérifiez son nom dans le dépôt configuré avant installation.

Suivre les écritures dans un répertoire limité

Ouvrez une session dédiée et surveillez un seul répertoire. Cette commande reste au premier plan jusqu’à Ctrl+C.

sudo inotifywait -m -e create,modify,move,delete /var/log/mon-service

L’option -m garde la surveillance ouverte. Les événements demandés évitent d’afficher les simples consultations de fichier. Déclenchez ensuite l’action qui doit faire écrire le service, par exemple une requête de test ou un redémarrage déjà prévu.

Un résultat tel que CREATE application.log ou MODIFY application.log confirme que le noyau a vu l’opération dans ce dossier. Il ne dit pas encore si le contenu est correct. Lisez alors les dernières lignes du fichier :

sudo tail -n 30 /var/log/mon-service/application.log

Le guide suivre un log avec tail sert justement à relire le contenu après l’événement. Si le service n’écrit que dans systemd, gardez plutôt journalctl -u mon-service -f.

Faire un essai sans toucher au service

Avant d’observer une application de production, prenez un dossier de laboratoire. Vous vérifiez ainsi la syntaxe et les droits sans mélanger vos événements avec ceux d’un service actif.

mkdir -p /tmp/inotify-test
inotifywait -m -e create,modify,move,delete /tmp/inotify-test

Dans une seconde session, créez puis modifiez un fichier :

printf 'premiere ligne\n' > /tmp/inotify-test/probe.log
printf 'seconde ligne\n' >> /tmp/inotify-test/probe.log

La première session doit afficher au moins une création et une modification. Arrêtez-la avec Ctrl+C, puis supprimez le dossier de test si vous n’en avez plus besoin.

Je choisirais cette vérification avant une modification de configuration, car elle répond à une question simple : le service atteint-il vraiment le répertoire attendu ? Elle ne permet pas de conclure sur la qualité du contenu écrit.

Les limites d’inotifywait en production

inotify observe les événements locaux transmis par le noyau. Sur un répertoire très actif, la sortie devient vite difficile à exploiter et la file d’événements peut déborder. Il faut alors revenir aux logs applicatifs, aux métriques ou à un audit adapté.

Ne l’utilisez pas comme preuve unique pour une enquête de sécurité. Évitez aussi les dossiers contenant des secrets ou des milliers de fichiers temporaires. Pour identifier un processus qui retient un fichier ou un port, lsof répond à une autre question.

Quand l’événement et le contenu du fichier correspondent à l’action de test, vous avez une base propre pour continuer le diagnostic. Si aucun événement n’apparaît, revérifiez le chemin, l’unité systemd et le type de journal avant de changer le service.

Pour le comportement exact des options, consultez la page de manuel d’inotifywait.