Hallo zusammen,
ich bin noch recht neu in der CheckMK Gemeinde, daher entschuldige ich mich schon mal im Voraus falls ich etwas ausführlichere Erklärungen brauche.
Ich habe auf einem Ubuntu 18.04.5 LTS Server in der MS Azure Cloud eine CheckMK Installation in der Version 1.6.0p19 (RAW Edition) im Einsatz. Ich habe auf dem Server nur eine Site angelegt und auch kein Distributed Monitoring konfiguriert.
Die täglichen Site Backups nach “/tmp” liefen jetzt 2-3 Monate ohne Probleme durch, seit einer Woche laufen die allerdings auf Fehler.
Die erste Fehlermeldung die ich gesehen hatte lautete wie folgt.
— Starting backup (Check_MK-“servername”-“sitename”-backup1 to local) —
Found previous incomplete backup. Cleaning up those files. Site backup failed: Failed to perform backup: [Errno 5] Input/output error
Wenn ich mir das /tmp Verzeichnis anzeigen lasse, sehe ich folgende Dateien / Ordner diesbezüglich.
# ls -lh /tmp
drwxrwxr-x 2 mysite omd 4.0K Mar 10 09:16 Check_MK-aznagios.pvs+ff.com-mysite-backup1-incomplete
-rw-rw---- 1 mysite omd 0 Mar 10 08:48 mkbackup.lock
Ich habe testweise den Ordner und die Datei gelöscht und das Backup händisch über omd backup mysite /tmp/test.tgz
ausgeführt. Hier erhalte ich ebenfalls den Errno 5.
Wenn ich das Backup unter /opt/omd/sites/mysite/tmp/ speichern möchte, erhalte ich selbige Fehlermeldung.
In den Log- Dateien habe ich nichts von dem Backup-Versuch gefunden, oder bisher nicht die richtige Log-Datei gefunden.
Leider hat meine bisherige Recherche in Bezug auf CheckMK und dem Errorcode zu keinem Ergebnis geführt. Wenn ich generell nach dem Fehler suche, finde ich zwar Aussagen darüber, dass ein Hardwaredefekt (Festplatte) vorliegt, aber das möchte ich bei einem Server welcher in Azure-Cloud läuft ausschließen.
das errno 5 ist nicht checkmk spezifisch sondern kommt von einem der unterliegenden Befehle. Ich vermute ein mv, cp oder Archivbefehl.
I/O Errors treten häufig auf, wenn es sich um gemountete Verzeichnisse (/tmp) handelt, die einen Fehler in der Vergangenheit haben. Kannst du prüfen, ob du die regulären Befehle im Verzeichnis ausführen kannst und auch die Dateiberechtigungen auf deinen site-User passen?
die Berechtigungen hatten soweit gepasst und ich konnte in dem Verzeichnis mit dem site-User auch Dateien kopieren usw.
Ich konnte das ganze jetzt zwar durch den Tipp das es Systemseitig sein muss lösen, verstehe aber die Hintergründe nicht ganz, da es doch mit CheckMK Dateien zu tun hatte.
Ich habe mir die Syslog Datei des Systems angeschaut und hier ist mir eine Fehlermeldung aufgefallen, welche sich immer wiederholte nachdem ich ein Backup der Konfiguration startete: EXT4-fs error (device sda1): ext4_find_extent:920: inode #1806563: comm omd: pblk 3735488 bad header/extent: invalid magic - magic 6f63, entries 28013, max 28261(0), depth 116(0)
Also habe ich im Dateisystem nach der Inode Nummer 1806563 gesucht und folgendes Ergebnis erhalten. # find / -inum 1806563 -ls 1806563 212 -rw-rw-r-- 1 mysite mysite 209037 Jan 26 14:12 /opt/omd/sites/mysite/var/check_mk/logwatch/fqdn-Servername/System
Ich habe dann kurzer Hand den dort aufgeführten Server über die WATO Konfiguration gelöscht und neu angelegt. Jetzt funktioniert auch das Backup wieder.
Oh, das klingt nach einem korrupten Filesystem. Ich glaube, du solltest bei Gelegenheit einen fschk über deinen Server laufen lassen.
EDIT:
Der Fehler lag dann hier an der Ursprungsdatei und nicht der Zieldatei. An der Stelle konnte er nicht alle Blöcke der Quelldatei lesen, weil dort an den Metadaten der Datei etwas schief war.
Ich kämpfe bereits seit letzter Woche, hier mal ein fsck laufen zu lassen.
Auf Grund dessen das die VM in der Azure Cloud läuft, habe ich allerdings nicht die Möglichkeit das Filesystem Offline prüfen zu lassen.
Hatte mittlerweile auch herausgefunden, dass die VM, wegen eines Hardwarefehlers der Hosthardware, automatisch neu bereitgestellt wurde und seit dem Tritt auch das Problem auf.
Kurz um liegt das Ganze jetzt mal beim Microsoft Support.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact @fayepal if you think this should be re-opened.