rm -rf problem auf ubuntu 9.04

710
PixelSmack

Ok, das ist eine Art gelöstes Problem, aber ich interessiere mich immer noch für das, was dahinter steckte.

Ich baue schon seit einiger Zeit Chrom von der Quelle und entschied mich, den src directroy und alle meine aktuellen Builds loszuwerden und von vorne zu beginnen (change of build config). Also wollte ich rm -rf verwenden, um das ./src/-Verzeichnis zu löschen. Das Verzeichnis ./src/out/Debug/ war mit / opt / chrome verknüpft, und die Binärdatei wurde auf meiner Gnome-Do-Docky-Leiste verlinkt.

Beim Versuch, das SRC-Verzeichnis zu rm -rf zu bekommen, bekam ich nach etwa einer Sekunde eine vollständige Sperrung meiner GUI. Nichts reagierte, einschließlich der Versuche, Runlevel zu ändern. Die Box reagierte immer noch auf einen Ping, obwohl ich keinen Opensh-Server installiert hatte. Dies erlaubte mir nicht, irgendetwas anderes zu versuchen. Das ist zweimal passiert. Beim dritten Mal entfernte ich sowohl das Symlink-Verzeichnis als auch das Gnome-Do-Symbol und das Löschen funktionierte ... Hat jemand eine Ahnung, was hier passiert ist und was es verursacht haben könnte?

1

2 Antworten auf die Frage

1
EmmEff

Haben Sie fsck auf diesem Dateisystem ausgeführt? In den Sektoren, in denen diese Dateien gespeichert sind / waren, kann es zu einer Beschädigung des Dateisystems kommen oder die Festplatte ist defekt.

Ich wollte einen rekursiven Symlink vorschlagen, aber mein kurzes Experimentieren konnte das beschriebene Verhalten nicht auslösen.

1
nagul

Ich würde den Vorschlag von EmmEff ablehnen. Es ist ziemlich üblich, dass das System einfriert, wenn einige Befehle E / A-Vorgänge blockieren. Dies kann auf fehlerhafte Sektoren auf der Festplatte zurückzuführen sein - überprüfen Sie sie mit den Befehlen fsck oder badblocks. Stellen Sie jedoch sicher, dass Sie die Optionen übergeben, um einen zerstörungsfreien Test durchzuführen. Das andere, häufiger auftretende Problem ist, dass Sie sich in einem Netzwerk-Dateisystem befinden und Latenzzeiten bei E / A-Vorgängen aufweisen.

Verwenden Sie smartctl, um die Festplatte zum Selbsttest an sich selbst zu veranlassen. Wenn es schlecht läuft, kaufen Sie eine neue und kopieren Sie. Minimieren Sie die Anzahl der Schreibvorgänge. def. Verwenden Sie fsck nicht zur Reparatur vor Ort auf einer fehlerhaften Festplatte! Peter Cordes vor 14 Jahren 0