Rsync beenden/cancel

[alter_Bekannter]

Wie stoppe ich eine größere rsync operation?
Also permanent stoppen nicht pausieren, so das ich auch den rsync overhead los werde.

Edit:
Der Overhead wurde vermutlich durch einen Dateisystemfehler verursacht. So genau ist das noch nicht geklärt. Da kamen wohl ein paar ungünstige Zufälle zusammen die die Aufklärung etwas behindert haben.
Konkret wurden etwa 30GB nicht als frei markiert. Weswegen ich von größerem temp aufkommen durch rsync ausging. Jetzt ist aber auch wieder alles korrekt.

Vielleicht war es auch kein Dateisystemfehler sondern der kleine Intel Atomprozessor hat einfach nicht rechtzeitig die Signale senden können die er hätte senden müssen weil die operation iihn zu fast 100% ausgelastet hat.
Letztlich werde ich davon ausgehen das es vermutlich irgendwas in der Richtung war. Das es nur temporär war legt hatl den Auslastungsschluss zumindest als Teil des Problems nahe.

Abgesehen davon gabs kein Problem weil ich nur im Halbschlaf in die falsche Richtung gesynct habe.

 

[Metal_Warrior]

Erst
[src=bash]ps ax | grep rsync | grep -v grep[/src]

Dann hast du alle deine Prozesse, bei denen in der Kommandozeile rsync steht. Jetzt suchst du dir den richtigen raus, merkst dir die Prozess-ID (PID) und tippst

[src=bash]kill $PID[/src]

Fertig.

 

[alter_Bekannter]

Die Variante entfernt auch all den erstellten Temporären kram?

Außerdem laufen 2 Prozesse die dazugehören, spielt die Reihenfolge eine Rolle?

 

[Metal_Warrior]

Der Befehl sendet den Beenden-Befehl an den Prozess, er schlachtet nicht. Also sollte das temporäre Zeug auch gelöscht werden (allerdings bin ich mir gar nicht sicher, ob da überhaupt großartig was angelegt wird).

Wenn es zwei Prozesse gibt, stellt sich erstmal die Frage, warum. Die Reihenfolge selbst ist nicht wichtig, sie zeigt im Normalfall nur an, welcher Prozess älter ist. Du kannst dem Kill-Befehl auch beide PIDs übergeben.

Mal ne andere Frage: Wieso dauert bei dir rsync so lange? Normalerweise braucht er nur beim ersten Mal so lang, sobald du nur die Daten updatest (Schalter: u), überschreibt er nur Änderungen in den jeweils geänderten Dateien.

 

[alter_Bekannter]

Oh da wird großartig was angelegt, das ist der Grund warum ich beenden will.

Wir sind hier schon bei locker 40GB "nicht großartig was".

Gesamttransfervolumen ca 1TB.

Ist allerdings eine reine Datenpartition daher ist das System dadurch nicht beeinträchtig.
Das Zielsystem ist nicht das Quellsystem transfer über ssh.

 

[Metal_Warrior]

@alter_Bekannter: Mir war schon bewusst, warum du es verwenden willst - ich mach das ja auch mit meinen Systemen ständig so. Mir ist aber noch nie eine relevante Menge temporärer Daten aufgefallen, die dabei erzeugt werden, geschweige denn irgendwas im GB-Bereich. Selbst bei nem TB nicht. Das würde ja runterskalieren auf meine täglichen Mengen mit etwa 7 GB temporärer Daten - das wäre mir im Monitoring schon längst aufgefallen. Schreib mal den Befehl hier rein, den du verwendest, vielleicht hast du irgendeinen witzigen Schalter an, den man wegoptimieren kann.

 

[alter_Bekannter]

rsync -avz -e 'ssh' /daten/ user@domain.de:/daten


z könnte unproduktiv sein, das meiste lässt sich vermutlich nicht groß komprimieren und ein System hat nur eine Atom CPU.
Aber erstmal müsste ich beenden, das QuellFS ist voll. Ich kann zwar platz schaffen damit ich rsync fortsetzen kann und dann ordentlich beenden, aber das wars auch schon rsync weiterlaufen lassen scheint keine Option.

Edit:
kill hat mir den Speicher nicht wiedergebracht und rsync schien auch nicht völlig davon überzaugt zu sein:

rsync error: unexplained error (code 143) at rsync.c(632) [sender=3.1.1]

Gibt es keinen expliziten beenden und abbauen befehl für rsync? Ich meine das aktuelle Spiel kann ich auch nicht endlos wiederholen. Mein Hauptproblem ist das ich irgendwann fertig werden will und rsync scheint in diesem Scenario keine Lösung zu sein, zumindest nicht im aktuellen durchlauf.

 

[Metal_Warrior]

Ich glaub, die Verbosity ist bei dir das Problem - da können durchaus ne Menge Metadaten anfallen. Außerdem ist die Kompression nicht frei von Temporärdaten. Ich hab mal etwas optimiert:

[src=bash]rsync -ahuP --stats /daten/ user@domain:/daten[/src]

a behält alle Dateisystemrechte, Zeiten, User und Gruppen bei und kopiert alle Unterverzeichnisse inklusive Gerätedateien (nur root) und Symbolic Links
h lässt die Ausgabe menschenlesbar werden, d. h. zeigt statt 1048576 halt 1 MiB an
u ist die Update-Funktion, sie kann mit --delete verwendet werden, wenn du gelöschte Dateien der Quelle auch im Ziel löschen willst - ist spätestens beim zweiten Lauf eine extreme Verkürzung der Übertragungsdauer
P schließt --partial und --progress mit ein, d. h. er fährt fort, wo er beendet wurde und zeigt dir den Fortschritt an (das, was du eigentlich mit der Verbosity wahrscheinlich haben wolltest)
stats zeigt dir die Statistiken am Ende an

z ist die Kompression, die aber auch temporäre Daten anfallen lässt. Lass sie weg, wenn du sie nicht unbedingt brauchst.
e kannst du weglassen, das Standardprotokoll für Remoteverbindungen ist ssh. Wird hauptsächlich verwendet, um einen bestimmten SSH-Befehl zu übergeben, wie etwa welche Keyfile zur Authentifikation verwendet werden soll etc.

Um dir deinen Speicher wieder zu leeren (ich nehme an, es ist ein Raspi oder ähnliches), kannst du mal mit
[src=bash]du -h[/src]
durch die Ordner zappen, damit du siehst, wo genau die Temporärdaten angelegt wurden und sie ggfs. manuell löschen. Ich hätte eigentlich drauf getippt, dass es in /dev/shm (RAM) liegt, oder alternativ in /run, /tmp, /var/run oder /var/tmp.

P.S.: Kill ohne irgendein Zusatz ist bereits der "reguläre" Abbaubefehl, also SIGTERM. Wenn du natürlich -9 (also SIGKILL) gemacht hast, beendet sich nicht rsync selbst, sondern das System zerstört den Prozess, was natürlich den Müll überall rumliegen lässt.

P.P.S.: Nachdem du mit Verbosity gearbeitet hast, bin ich mir nicht sicher, ob rsync nicht fleißig das Syslog mit den Metadaten befüllt hat, was zu deinem Speicherproblem geführt haben kann. Guck also auch mal in /var/log/.

 

[alter_Bekannter]

Uhm, var log kann nicht das Problem sein, sonst wäre mein System tot.

Wie ich schon sagte ist der Speicher nur auf der betroffenen Datenpartition weg.
Alle anderen Partitionen, zum Beispiel die wo /var/log liegt sind nicht betroffen.

Um das mal klar zu stellen:
/dev/sda5 1,3T 1,3T 0 100% /data

Das allein ist das Problem alle anderen Filesysteme sind in Ordnung. Deswegen läuft das Teil ja noch stabil und nur rsync will nicht mehr wirklich.

"/" zB ist total grün, unter 50%. Da hat sich nix nennenswert geändert. Es ging wirklich nur um eine Datenpartition. Meine Pornosammlung, nicht mein OS.

 

[Metal_Warrior]

@alter_Bekannter: Dann schau mal nach, ob der die Kompressionsdaten dort abgelegt hat. Wie gesagt, "du" hilft bei der Identifikation.

Kleine Hilfe an der Stelle noch: Ich gehe davon aus, dass rsync Kompressionsdaten im jeweiligen Ordner anlegt und mit einem vorangestellten Punkt markiert. Du könntest also mal mit find drüberschauen, ob du irgendwelche größeren Datenmengen mit vorangestelltem Punkt findest.

Edit: Den Befehl dafür noch:
[src=bash]find /daten -name '.*' > ~/Hidden.txt[/src]

 

[alter_Bekannter]

"du" listet die verlorenen GB scheinbar nicht.

Ne Ahnung wo ich noch suchen könnte? reserviert rsync vielleicht auch einfach einen riesen Arsch voll Speicher den ich nicht in Form von Dateien/Ordnern sehen kann?

"du" listet mir nur die Sachen die ich auch so sehen kann.

edit:
Wie könnte ich ales listen was "neuer ist als". Die Liste wäre vermutlich hilfreicher, denn rsynch habe ich erst gestern gestartet und seitdem kam nix mehr dazu sonst. Wie gesagt da liegt nix vom System so grobes Werkzeug kann da angewendet werden. Das ist quasi nur ein Downloadverzeichnis. Da liegen auf der ganzen Parttion keine Logs oder sonstwas das ohne mein aktives zutun sich ändert. Oder vom System automatisch verwertet wird. Das Heisst die gewollten Daten sind alle "alt".

find /data/ -mmin -1200 # modification time

Lieferts auch nicht aber sonst ist das Ergebnis wie erwrtet.

edit2:
Dateien löschen(auch mehrere GB) machen sich nicht als freier Speicher bemerkbar es muss also irgendeine Reservierung sein, nicht bereits existierende Daten. Das hätte ich vielleicht mal viel früher erwähnen sollen...

edit3:
Das "du" versteckte Dateien mitlistet habe ich auch selber schon getestet. Aber nein, find liefert nichts annähernd auffälliges. Vor allem viel zu wenig und viel zu klein.(Und falsche Ordner)

Eine Legitime "vermutlich temp" datei habe ich zwar gefunden, aber das ist wirklch nur die der Datei die er aktuell kopiert. Wenn das alles wäre hätte ich den Thread garnicht geöffnet. Dann wärs vermutlich schon fertig.

 

[Metal_Warrior]

Also irgendwas frisst dir den Speicher, während du ihn leerst - was läuft bei dir auf dieser Platte auf? Gibt es irgendeinen Prozess, der automatisch auf die Platte schreibt? rsync kanns ja mal nicht sein.

Zum Finden der neuesten Dateien wäre ein kleines Skript nötig, oder ein Spaghetti-Einzeiler. Ich probier grad mal was und schreibs dir hier als Edit rein.

[src=bash]#!/bin/bash

# Alle Dateien mit vollem Pfad in 1.txt schreiben
find /daten -type f > 1.txt
# Environment säubern
rm 2.txt
# Jede einzelne Datei abfragen und prüfen, ob heute geändert. Wenn ja, mit vorangestellter Bytegröße in 2.txt schreiben
while read LINE
do
TEMP="`ls -1l $LINE | grep "Jan 16" | cut -d " " -f 5 -s` $LINE"
echo "$TEMP" >> 2.txt
done< 1.txt
# nach Größe sortieren (aufsteigend)
sort 2.txt > 3.txt
exit 0[/src]

 

[alter_Bekannter]

Warte mal ich glaube ich habe das Problem gefunden, will aber jetzt keinen Schnellschuss geben. Ich denke nämlich ich habe ganz am Anfang alles auf eine Fehlannahme gestützt und in der Mitte eine Kontrolle übersprungen. Um sicher zu stellen das ich nicht nur den Rest meines Verstandes verliere prüfe ich das erstmal bis morgen.

Duie neuesten Datein finden tut ein Einzeiler den ich schon gepostet habe. Also mach dir darüber mal keine Gedanken.

 

[redbeard]

Ob rsync (oder irgendwas anderes) noch halbtote Files offen haelt, kannst du mit

[src=bash]lsof +L1[/src]

pruefen.