Der Container las brav neu — nur eben dieselbe alte Datei

Das Symptom: Nach dem Rollout fehlte ein neu hinzugefügter Scrape-Job im Zeitreihen-Speicher. Statt 25 Zielen zeigte er weiter 24. Die Konfigurationsdatei auf der Platte enthielt den Job — nachgezählt, sie war korrekt. Ein SIGHUP an den Container änderte nichts.

Die Gegenprobe brachte es an den Tag. Einmal auf dem Host, einmal im Container, derselbe Pfad:

grep -c "flow-collector" prometheus/prometheus.yml
# 1  — auf dem Host
 
docker exec <container> grep -c "flow-collector" /etc/prometheus/prometheus.yml
# 0  — im Container

Zwei verschiedene Dateien am selben Pfad.

Die Ursache: Die Datei hängt als Bind-Mount im Container — nicht das Verzeichnis, die einzelne Datei. Und git pull aktualisiert eine Datei nicht an Ort und Stelle: Es schreibt eine neue und tauscht sie ein. Neue Datei heißt neue Inode. Der Mount zeigte weiter auf die alte, die es im Verzeichnis gar nicht mehr gab.

Deshalb half der Reload nicht. Der Prozess las gehorsam neu — nur eben dieselbe alte Datei.

Die Lösung ist unspektakulär: Container neu erstellen, nicht neu laden.

docker compose up -d --force-recreate <dienst>

Die Zeitreihen liegen in einem benannten Volume und blieben unberührt. Danach 25 Ziele, alle erreichbar.

Was ich mitnehme: Ein Bind-Mount auf eine einzelne Datei ist eine Wette darauf, dass niemand die Datei ersetzt. git pull tut genau das, sed -i und die meisten Editoren übrigens auch. Wer Konfiguration so einbindet, muss den Container neu erstellen — ein Reload ist dann wirkungslos, und zwar lautlos. Das Verzeichnis zu mounten statt der Datei hätte das Problem gar nicht erst entstehen lassen.