Postfix init.d Skript wird in Verzeichnis angezeigt aber nicht gefunden

[Marentis]

Folgendes Verhalten habe ich soeben in einem Virtuozzo Container (Debian 6 mit Plesk) festgestellt:
Postfix ließ sich nicht mehr entfernen (Wechsel auf Qmail und wieder zurück, lt. Aussage eines Parallels Mitarbeiter, aufgrund eines Problems bei der Anlage von Mailboxen), da das init.d skript nicht gefunden wurde, wodurch dann auch ein apt-get remove fehlschlug (dpkg Fehler).

Daher einmal nachgeschaut mit ls und siehe da: in /etc/init.d befindet sich "postfix". Daher der Versuch die Datei erst einmal mit "mv" aus dem Weg zu schieben -> No such file or directory.
Jetzt wurde ich stutzig und versuchte es mit einem echo * im selben Verzeichnis (falls ls korrumpiert wurde). Postfix immer noch zu sehen.
Gut, den Container also mal in den Repairmode gebootet -> Dort (repair/etc/init.d/) ist die Datei zu sehen (clear as day). Dann spaßeshalber dort ein "mv" versucht, selber Fehler: No such file or directory.
Meine Vermutung: entweder ist das Dateisystem im Eimer (aus welchen Gründen auch immer) oder der Host wurde infiziert. Der Container selbst kann nicht direkt betroffen sein, da der Fehler ja auch im Reparaturmodus auftritt.

Habt ihr dieses Verhalten schon einmal erlebt? Google war nicht sehr hilfreich und die üblichen Methoden wie fsck (falls es doch am Dateisystem liegt) kann ich ja nicht durchführen, weil ich nicht an den Host kann.

Ansonsten habe ich den Container jetzt erstmal gestoppt, Fehler die ich nicht nachvollziehen kann machen mich definitiv stutzig.

Ps: Ich bin mir nicht absolut sicher ob es an der Virtualisierung per se liegt oder an Linux. Ein Moderator möge den Beitrag bitte verschieben, falls ich mich vertan habe. Ich weiß schon warum ich KVM und nackte Dedis ohne Plesk liebe, da weiß ich wenigstens, dass es zu 100% meine Schuld ist und wo ich hinfassen muss.

 

[wstuermer]

Was sagen denn:

lsattr /etc/init.d/postfix
file /etc/init.d/postfix
stat /etc/init.d/postfix
df -h
df -i

 

[Marentis]

lsattr muss ich leider passen, da ich momentan auch keine Pakete mehr installiert bekomme, da sich die Paketverwaltung durch diesen Fehler "gefressen" hat. Selbst purge hilft nicht mehr, weil die Datei "im Weg" ist.
Die restliche Ausgabe:

root@200019:~# file /etc/init.d/postfix
/etc/init.d/postfix: ERROR: cannot open `/etc/init.d/postfix' (No such file or directory)
root@200019:~# stat /etc/init.d/postfix
stat: cannot stat `/etc/init.d/postfix': No such file or directory
root@200019:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vzfs       100G  1.2G   99G   2% /
root@200019:~# df -i
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/vzfs      5000000 69005 4930995    2% /

Ps: Herzlichen Dank für die Hilfe!

 

[wstuermer]

Eine Vermutung wäre noch, dass der Dateiname nicht nur "postfix" lautet, sondern noch irgendwelche Spaces oder sonstige unsichtbaren Zeichen enthält.
Hast du mal versucht mit "/etc/init.d/postf[TAB]" zu vervollständigen? Ansonsten navigier mal -sofern installiert- mit "mc" zu der Datei.

 

[Marentis]

Ja, ich nehme immer Tab (schon aus Faulheit), da ich eine ähnliche Vermutung hatte. Dagegen spricht aber auch, dass bei Spaces dpkg nicht darüber stolpern sollte.

Ich habe jetzt den Paketmanager notdürftig "geflickt", indem ich ein Backup von gestern morgen eingespielt habe. Dort geht dkpg noch, weil ich zu diesem Zeitpunkt den Wechsel zwischen Postfix und Qmail noch nicht probiert hatte (Plesk ist aber schon "kaputt"). Postfix war jedenfalls zu diesem Zeitpunkt schon kaputt, ist aber eben erst aufgefallen, als ich mit Plesk zwischen Qmail und Postfix wechseln wollte (weil genau dann dpkg versucht Postfix zu entfernen).

Dann habe ich auch gleich die e2fsprogs geholt, Resultat:

root@200019:~# lsattr /etc/init.d/postfix
lsattr: No such file or directory while trying to stat /etc/init.d/postfix

MC "sieht" die Datei auch, lässt sie mich auch auswählen. Sobald ich dann F8 drücke kommt aber

"Cannot delete file "/etc/init.d/postfix" No such file or directory (2)"

Man sieht am angehängten Screenshot auch schön, dass es ein kaputter Symlink ist aber das sich so einer nicht mehr entfernen lässt wäre mir neu :O.

Ich werde die ganze Kiste einmal neu aufsetzen. Normalerweise würde ich das Backup gerne in einer VM auseinander nehmen aber das fällt ja aus.

 

[Joe User]

Da scheint das Filesystem einen Defekt zu haben. Zufällig Ext4?

 

[Marentis]

Ich weiß nicht welches Filesystem der Host verwendet, da es ein Virtuozzo Container ist und dort nur Images bereitgestellt werden. Ich kann auch keine individuellen Images booten o.ä., sondern bin hier konkret auf das angewiesen, was mir der Hoster zur Verfügung stellt.

Eine meiner Vermutungen ging auch in die Richtung defektes Filesystem aber das Filesystem kann nur am Host geprüft werden *angeblich*, bitte Infos falls ich hier falsch liege. Im Grunde könnte ich lediglich den Support anschreiben und darum bitten, dass man das Filesystem der zu Grunde liegenden Platten prüft aber das werden die kaum tun und sich - vermutlich - darauf zurückziehen, dass es ein Problem direkt mit dem vServer sei, was ich natürlich keineswegs ausschließen kann.

Ich weiß schon warum ich dieses Zeug nie hätte anfassen sollen, zerschieße ich mir eine KVM oder einen Dedi weiß ich wenigstens, dass ich alleine zu 100% irgendwo etwas kaputt gemacht habe und wie ich es behebe. Plesk und Virtuozzo bleiben für mich eine Blackbox.

Ps: Ich habe jetzt - als Experiment - einmal die Neuinstallation des Containers beauftragt, das selbe Setup. Diesmal sehe ich sofort nach der Datei "Postfix", ich bin gespannt, ob es sich ggfls. um ein korruptes Image handelt.