Prozess lässt sich nicht beenden - Warum?

SBI · 29 Dez. 2005

Hallo,

ich hatte schon öfters mal ein Prozess der sich nicht beenden ließ.
Jetzt sitze ich wieder vor so einem Problem.
Externe Firewire Festplatte lässt sich nicht aushängen, da sich

Code:

rsync

sehr oft aufhängt. (Weiß aber ned warum? Wird zur Datensicherung genutzt. Kann mir auch ned erklären warum sich rsync öfters aufhängt. Somit ist die Datensicherung nicht immer aktuell.)
Ich habe es schon mit

Code:

kill und killall

versucht, aber der Prozess lässt sich ned beenden.

Gibt es noch andere Möglichkeiten?

Vielen Dank im Voraus!

ninguno · 29 Dez. 2005

welches signal hast du denn mit kill geschickt? wenn 15 (SIGTERM), 2 (SIGINT) und 1 (SIGHUP) nichts nutzen, kannst du als letzte möglichkeit das signal 9 (SIGKILL) senden. SIGKILL ist aber unsauber, weil dem prozess damit keine zeit gegeben wird sich ordnungsgemäss zu beenden, somit können temp files über bleiben, sockets offen et.

basman · 29 Dez. 2005

Wenn es Hardware-Lesefehler auf dem Medium gibt, hängt rsync während den Schreib- oder Leserequests im Kernel. Das erkennt man i.d.R. am Process-Status "D" (sichtbar mit ps aux). Kann bei externen Medien aber auch an Kommunikationsfehlern liegen. Dann hilft nicht mal kill -9, weil das Programm in einer Retry-Schleife auf Kernel-Ebene festhängt. Sobald die laufende Retry-Schleife durchlaufen ist, reagiert das Programm (rsync) auf das Kill-Signal.

Beobachte das kernel-log (Kommando: dmesg), ob der Kernel über derartige Probleme meckert (IO-error oder so).

SBI · 29 Dez. 2005

Vielen Dank erstmal für die schnellen Antworten!!!

@ninguno:
Ich habe alle Varianten mit kill ausprobiert. Auch SIGKILL.
Wird aber nicht beendet.

@basman:
Der Process-Status steht auf "D".
Sorry, aber wieso kann es denn zu Hardware-Lesefehler auf dem Medium kommen? Es sind 3 externe Festplatten im Einsatz (wird täglich gewechselt), das tritt bei allen 3 auf . Also vom Hardwaredefekt gehe ich mal ned aus.

Wie kann man die Retry-Schleife dazu bewegen das sie alles durchläuft?
Oder bzw. wie kann ich dieses Problem beheben?

SBI · 29 Dez. 2005

Kleiner Hinweis noch:

Auf dem Server ist ein SuSE 9.0 und rsync in der Version 2.5.6 installiert.

taki · 29 Dez. 2005

Das interessiert mich auch sehr.

Es gibt wohl eine Endlosschleife in der Kernel-Routine. Die schlägt nicht nur bei externen Laufwerken gelegentlich zu. Gelegentlich hat sie bei mir schon mal beim Zugriff auf "kopiergeschützte" Medien (Audio-CD und Video-DVD) zugeschlagen. Da finde ich es ziemlich blöd, dass man keine Möglichkeit hat, dem Kernel aus der Schleife herauszuhelfen :-/ Kann man irgendwo einen Timeout definieren, um solche Schleifen endlich werden zu lassen, so dass man rauskommt, ohne den Kernel neu laden zu müssen (d.h. ohne Reboot)?

ninguno · 29 Dez. 2005

hast du nen i/o timeout für rsync gesetzt (option --timeout) ?

basman · 29 Dez. 2005

taki schrieb:
Kann man irgendwo einen Timeout definieren, um solche Schleifen endlich werden zu lassen, so dass man rauskommt, ohne den Kernel neu laden zu müssen (d.h. ohne Reboot)?

Fehlgeschlagene Leseversuche auf kopiergeschützten Medien sehen für den Kernel genauso aus, wie echte Lesefehler.

Wenn man den Timeout ändern will, muss man meines Wissens nach den Kernel umprogrammieren. Es gibt zwar Mechanismen (Stichwort: Boot Parameter und ohne Reboot das /proc Filesystem) um unter Linux, am Kernel auch ohne Programmieren und anschliessendem Kompilieren Konfigurationswerte zu ändern, aber IO-Timeouts sind davon ausgeschlossen (soviel ich weiss).

Der D-Status kann auch auftreten, wenn bei der Kommunikation über USB Interrupts "verloren gehen". Szenario: ein Prozess (z.B. rsync oder grip) möchte einen Datenblock über USB lesen. Er teilt dies dem Kernel mit und wird schlafengelegt, damit während der Wartezeit auf das Lesen und Anliefern der Daten andere Prozesse laufen können. Das USB-Gerät erhält die Anfrage, fährt seine Leseköpfe in Position, saugt die Daten vom Medium in den internen Cache und meldet dem PC, die Daten lägen zur Übertragung bereit.

Nun kann es bei fehlerhafter USB-Schnittstelle am PC oder sonstigen Interrupt-Problemen (z.B. ACPI bezogen -> Boot option pci=noacpi) zum Übersehen der Bereitschaftsmeldung seitens des PCs kommen. Normalerweise merkt der Kernel das und meckert leise vor sich hin (mit Kommando dmesg kann man diese Fehlermeldungen sichtbar machen). Gleichzeitig bleibt der Prozess im blockierten Zustand, weil seine Daten ja noch immer nicht da sind. (Andere Prozesse laufen jedoch ungehindert weiter - ein Verhalten, was ich an Linux sehr schätze. Unter Windows bringt eine defekte Disk meist das ganze System zum Stehen.)

Interrupts sind "Meldeschnittstellen", um selbst einen sehr beschäftigten PC innehalten zu lassen, um Mausbewegungen oder neu angekommene Netzwerkpakete zu beachten.

Sorry, falls ich zu ausführlich wurde. Fazit: dmesg Ausgabe anschauen, dann erfährt man eher, woran es genau liegt.

SBI · 30 Dez. 2005

Hi,

@ninguno:
Danke für den Tipp!
Die Option --timeout habe ich ned in Benutzung.
Momentan synchronisiere ich mit folgenden Optionen:

Code:

rsync -aHv --delete-after Quelle Ziel

Ich werde aber die Option hinzufügen!
Auf wie viel Sekunden sollte man denn den Timeout setzen, 180?
Welche Optionen machen denn noch Sinn?
-b -u --ignore-errors?

@basman:
(Die Boot option pci=noacpi wird bei den Server aber ned verwendet.)
Also kann man so einen festgefahrenen Prozess ned irgendwie beenden/killen, ohne den Server neu zu starten?

basman · 30 Dez. 2005

SBI schrieb:
(Die Boot option pci=noacpi wird bei den Server aber ned verwendet.)
Also kann man so einen festgefahrenen Prozess ned irgendwie beenden/killen, ohne den Server neu zu starten?

Die Boot-Option sollte eventuelle Hardwareprobleme beheben, so dass Prozesse, die von problematischen Geräten lesen erst gar nicht in den D-Status kommen. Das hilft aber nur in dem Fall, wenn keine physikalischen Fehler auf dem Datenträger vorliegen, sondern das Problem am Hardware-Design liegt.

Unabhängig davon:
Bei Prozessen im D-status kann man entweder warten, bis sich diese von selbst beenden (ein kill -9 sollte man auf jeden Fall senden, sonst läuft er einfach sofort wieder in eine Retry-Schleife) oder den Rechner neu starten.

SBI · 30 Dez. 2005

basman schrieb:
Die Boot-Option sollte eventuelle Hardwareprobleme beheben, so dass Prozesse, die von problematischen Geräten lesen erst gar nicht in den D-Status kommen.

Unabhängig davon:
Bei Prozessen im D-status kann man entweder warten, bis sich diese von selbst beenden (ein kill -9 sollte man auf jeden Fall senden, sonst läuft er einfach sofort wieder in eine Retry-Schleife) oder den Rechner neu starten.

Prozess bei D-Satus - warten bis er sich beendet dauert zu lange. Ich warte ja schon ein paar Tage.

Und ein Server öfters mal neu starten is ned so angebracht.

Ich werde die Boot-Option und bei rsync das timeout hinzufügen.
Mal schaun.

Vielen Dank soweit!