Beobachten Sie eine Datei mit inotifywait, um das Schreiben eines Dienstes zu bestätigen

Ein Dienst scheint zu laufen, aber die erwartete Datei bleibt leer. Bevor Sie seine Konfiguration ändern oder Hunderte von Zeilen in journalctl durchsuchen, schauen Sie sich direkt das Verzeichnis an, in das er schreiben soll.

inotifywait zeigt die vom Kernel erkannten Erstellungen, Änderungen und Bewegungen an. Sie können eine begrenzte Schreiboperation bestätigen und dann feststellen, wann dieses Tool nicht mehr ausreicht.

Den Pfad identifizieren, bevor Sie die Überwachung starten

Beginnen Sie mit dem absoluten Pfad. Ein systemd-Dienst kann in /var/log/nom-service, in einem Anwendungsverzeichnis oder nur im Systemprotokoll schreiben. Überprüfen Sie unter Debian und Ubuntu zuerst die Einheit und deren Protokolle:

sudo systemctl status mein-dienst --no-pager
sudo journalctl -u mein-dienst -n 50 --no-pager

Wenn Sie bereits eine spezifische Datei haben, überprüfen Sie ihren Eigentümer, ihre Berechtigungen und den verfügbaren Speicherplatz. Eine Überwachung behebt weder ein fehlendes Verzeichnis noch einen vollen Datenträger.

sudo ls -ld /var/log/mein-dienst
sudo df -h /var/log/mein-dienst

Installieren Sie anschließend inotify-tools, falls der Befehl fehlt. Das Paket trägt denselben Namen unter Debian und Ubuntu.

sudo apt update
sudo apt install inotify-tools

Auf einem RHEL-, Fedora- oder Rocky-Rechner heißt das Paket ebenfalls normalerweise inotify-tools. Überprüfen Sie seinen Namen im konfigurierten Repository vor der Installation.

Die Schreibvorgänge in einem begrenzten Verzeichnis verfolgen

Öffnen Sie eine dedizierte Sitzung und überwachen Sie ein einzelnes Verzeichnis. Dieser Befehl bleibt im Vordergrund bis Ctrl+C.

sudo inotifywait -m -e create,modify,move,delete /var/log/mein-dienst

Die Option -m hält die Überwachung offen. Die angeforderten Ereignisse verhindern, dass einfache Dateiabrufe angezeigt werden. Starten Sie dann die Aktion, die den Dienst zum Schreiben bringen soll, beispielsweise eine Testanfrage oder einen bereits geplanten Neustart.

Ein Ergebnis wie CREATE application.log oder MODIFY application.log bestätigt, dass der Kernel die Operation in diesem Ordner gesehen hat. Es sagt jedoch noch nicht aus, ob der Inhalt korrekt ist. Lesen Sie dann die letzten Zeilen der Datei:

sudo tail -n 30 /var/log/mein-dienst/application.log

Der Leitfaden Logs mit tail verfolgen dient genau dazu, den Inhalt nach dem Ereignis zu lesen. Wenn der Dienst nur in systemd etwas schreibt, verwenden Sie besser journalctl -u mein-dienst -f.

Ein Versuch ohne den Dienst zu berühren

Bevor Sie eine Produktionsanwendung beobachten, nehmen Sie einen Laborordner. So überprüfen Sie die Syntax und Berechtigungen, ohne Ihre Ereignisse mit denen eines aktiven Dienstes zu vermischen.

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

In einer zweiten Sitzung erstellen und ändern Sie eine Datei:

printf 'erste zeilen' > /tmp/inotify-test/probe.log
printf 'zweite zeilen' >> /tmp/inotify-test/probe.log

Die erste Sitzung sollte mindestens eine Erstellung und eine Änderung anzeigen. Stoppen Sie sie mit Ctrl+C und löschen Sie dann den Testordner, wenn Sie ihn nicht mehr benötigen.

Ich würde diese Überprüfung vor einer Konfigurationsänderung wählen, da sie eine einfache Frage beantwortet: Erreicht der Dienst wirklich das erwartete Verzeichnis? Sie erlaubt jedoch keine Schlussfolgerung über die Qualität des geschriebenen Inhalts.

Die Grenzen von inotifywait in der Produktion

inotify beobachtet die lokalen Ereignisse, die vom Kernel übermittelt werden. In einem sehr aktiven Verzeichnis wird die Ausgabe schnell unübersichtlich und die Ereigniswarteschlange kann überlaufen. In diesem Fall müssen Sie zu Anwendungsprotokollen, Metriken oder einer geeigneten Prüfung zurückkehren.

Verwenden Sie es nicht als alleiniges Beweismittel für eine Sicherheitsuntersuchung. Vermeiden Sie außerdem Verzeichnisse, die Geheimnisse oder Tausende temporärer Dateien enthalten. Um einen Prozess zu identifizieren, der eine Datei oder einen Port hält, beantwortet lsof eine andere Frage.

Wenn das Ereignis und der Inhalt der Datei mit der Testaktion übereinstimmen, haben Sie eine saubere Grundlage, um die Diagnose fortzusetzen. Wenn kein Ereignis erscheint, überprüfen Sie den Pfad, die systemd-Einheit und den Protokolltyp, bevor Sie den Dienst ändern.

Für das genaue Verhalten der Optionen konsultieren Sie die man-Seite von inotifywait.