Root-Filesystem sporadisch read-only und alte Inhalte

  • Seit Freitag, den 4.9., habe ich sporadisch folgendes Verhalten bei meinem KVM Server beobachtet:


    Bei Zugriff auf den Webserver (nginx) wird kein Access-Log geschrieben, es wird scheinbar ein älterer Stand des Root-Filesystems verwendet (vermutlich von Freitag, da am Wochenende neu angelegte Files als "not found" gemeldet werden), und dieses Dateisystem scheint zudem read-only zu sein (Fehlermeldungen bei PHP Session-Schreiben, Datenbank-Verbindung fehlgeschlagen, Zugriffe erscheinen nicht im nginx access-Log).


    Gleichzeit ist Zugriff über die VNC-Konsole möglich - dort sieht alles aktuell und read-write-gemountet aus, jedoch erscheinen hier die Web-Zugriffe (während der o.g. Phasen) nicht im Access-Log. Wenn ich mich per SSH in dem Moment verbinde, lande ich scheinbar ebenfalls auf der read-only-"Instanz" mit älterem Filesystem (die gleiche, die auch die nginx/php-fpm Instanz "sieht"?). Auto-Completion in der Bash funktioniert aufgrund der fehlenden Schreib-Berechtigung ebenfalls dort nicht. Es wirkt fast so, als würde es zwei Instanzen des KVM-Servers geben. Eine SSH-Verbindung via PuTTY bricht auch regelmäßig ab, wenn der "Wechsel" von read-only zu read-write und umgekehrt stattfindet.




    Reboot behebt das Problem nur temporär. Rettungssystem und fsck habe ich bereits ausprobiert - ohne signifikante Fehler. Auf meine Vermutung, ob ein Hardware-Defekt oder ein sonstiges Problem beim Wirtssystem vorliegt, antwortet der Netcup-Support "Auf dem Wirtssystem sind keine Auffälligkeiten zu erkennen.".


    Hat jemand schon mal ähnliche Probleme gehabt oder hat weitere Vorschläge, was man hier machen kann? Ist derzeit eine äußerst unschöne Situation, da die Verfügbarkeit der gehosteten Websites ohne Datenbank-Connection gerade rapide abnimmt...


    System ist ein Ubuntu LTS 14.04 Minimal, nginx, php-fpm, keine Docker oder ähnlichen Geschichten, alle aktuellen Standard-Updates eingespielt, eigentlich nix fancy dabei...


    Danke für jegliche Hilfe!

  • Schon einmal ins Kernel-Protokoll gesehen, was für den Read-Only Remount verantwortlich ist? Das siehst Du auch ohne geschriebene Logs im laufenden System mittels dmesg | less.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Dort findet sich leider kein Hinweis dazu, es ist wie gesagt so, dass die fehlerhaften Zugriffe scheinbar auf einer anderen Instanz landen, da sie auch nicht im Webserver-Log auftauchen.


    In dmesg findet sich nur entsprechende Infos von der Startphase, hier mal die relevanten Einträge (=die mit vda drin):


    [ 0.740399] vda: vda1 vda2
    [ 1.138875] EXT4-fs (vda2): INFO: recovery required on readonly filesystem
    [ 1.140301] EXT4-fs (vda2): write access will be enabled during recovery
    [ 2.250528] EXT4-fs (vda2): orphan cleanup on readonly fs
    [ 2.253171] EXT4-fs (vda2): 9 orphan inodes deleted
    [ 2.255334] EXT4-fs (vda2): recovery complete
    [ 2.261664] EXT4-fs (vda2): mounted filesystem with ordered data mode. Opts: (null)
    [ 6.589445] Adding 975868k swap on /dev/vda1. Priority:-1 extents:1 across:975868k FS
    [ 6.667035] EXT4-fs (vda2): re-mounted. Opts: discard,errors=remount-ro

  • Noch eine Ergänzung: Seit meinem ersten Posting habe ich per uptimerobot.com einen Test auf eine neu erstellte Testseite laufen lassen (einfaches PHP-Skript, das einen DB-Connect herstellen soll und bei Erfolg eine entsprechende Ausgabe macht). In ca. 75% der Fälle war dies erfolgreich (und damit die Antwort von der "richtigen" Instanz), in den anderen Fällen kam ein "File not found" - der Webserverlieferte hier offensichtlich basierend auf dem veralteten Read-only-Filesystem von Freitag aus, in dem das Testscript noch nicht existierte. Diese Zugriffe erscheinen wiederum auch nicht im nginx Access Log da scheinbar auf einer anderen Instanz... Ideen willkommen!