Hi,

ich bekomm den selben Fehler wie hier:

rsync Fehler

und ich habe die ganzen Tipps leider ohne Erfolg ausprobiert. Ich konnte feststellen, dass der Fehler nur ab dem zweiten rsync auftaucht. Ist das Zielverzeichnis leer taucht kein Fehler auf. Den Fehler habe ich seit einem OS Update auf dem rsync-Server und ich habe deshalb den Client auch mal auf die neuste Version geupdatet. Ohne Erfolg Benütze ich allerdings nicht den rsync-daemon auf der Serverseite, sondern sync ich direkt (-e ssh) läuft seit dem Update alles sauber... aber ich will ja wegen Benutzerverwaltung und Berechtigungen etc. den Server benutzen.

Das hier ist die letzte Ausgabe:

send_file_list done

file list sent

send_files starting

rsync: connection unexpectedly closed (4 bytes received so far) [sender]

_exit_cleanup(code=12, file=io.c, line=453): entered

rsync error: error in rsync protocol data stream (code 12) at io.c(453) [sender=2.6.9]

_exit_cleanup(code=12, file=io.c, line=453): about to call exit(12)

Im ServerProtokoll kann ich nichts finden, ausser "rsync to $dir from $ip".

Jeder Tipp ist hilfreich, danke

Gruß

Jeder Tipp ist hilfreich, danke

Und 'ne genaue Angabe, was Du gemacht hast, erst mal

Rsync kennt etwa 100 Aufrufoptionen, welche hast Du benutzt?

Sry, das hab ich vergessen Aber hier der Aufruf:

rsync -avz /snapshot/ ${USER}@${SERVER}::${SHARE}/ --exclude-from=${EXCLUDE} --delete --quiet --timeout=3600 2>&1

Falls es euch hillft: Ein Start des Daemons mit strace bringt die Meldung:

[pid 25174] writev(2, [{"rsync", 5}, {": ", 2}, {"relocation error", 16}, {": ", 2}, {"/lib/libnss_compat.so.2", 23}, {": ", 2}, {"symbol _nss_files_parse_pwent, v"..., 103}, {"", 0}, {"", 0}, {"\n", 1}], 10rsync: relocation error: /lib/libnss_compat.so.2: symbol _nss_files_parse_pwent, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

) = 154

Das kommt laut google dann vor wenn ich glibc update aber den rsync-daemon nicht neu starte. Das habe ich inzwischen aber schon das ein oder andere mal gemacht...

rsync -avz /snapshot/ ${USER}@${SERVER}::${SHARE}/ --exclude-from=${EXCLUDE} --delete --quiet --timeout=3600 2>&1

Sieht ja erstmal nicht dramatisch aus, ich dachte zuerst an eine unglückliche Verkettung von Aufrufoptionen, wie hier

Tritt das Problem auch auf, wenn Du die compression mal rausnimmst?

Ne, das bringt leider nix, das hab ich schon versucht. Aber Ich finde es seltsam das es nur die SLES 8 Kisten betrifft, beim Rest läuft alles wie gewohnt....

Von wo nach wo geht's denn? Von SLES8 auf SLES10? Dann könnt's evtl. ein Codepage-Problem sein.

Ich selbst kenne die Probleme eigentlich nur wenn's irgendwelche große Dateien/Dateien mit Defekten sind die übertragen werden sollen. Hast schon mal versucht herauszufinden ob's evtl. Probleme mit ein paar Daten gibt? Evtl. den größeren Job in mehrere kleinere zerlegen. Das hat mich immer auf die Ursache der Probleme gebracht. Waren in der Regel Dateien die sich nicht kopieren lassen wollten.

Wobei wenn Du nicht über SSH/TLS arbeitetes, schon mal einen Netz-Dump erstellt?

Wobei wenn Du nicht über SSH/TLS arbeitetes, schon mal einen Netz-Dump erstellt?

Ja, das wollte ich auch gerade noch vorschlagen. Der Abgleich scheint ja zunächst zu klappen:

send_file_list done

file list sent

send_files starting

rsync: connection unexpectedly closed (4 bytes received so far) [sender]

Besonders diese ersten vier Byte wären ja evtl. interessant (wenn's denn jedesmal vier sind). Gerade weil der Abgleich zunächst klappt, das Schreiben dann aber nicht mehr (jedenfalls nicht beim zweiten Mal), kam mir gerade auch noch das Thema Zugriffsberechtigungen in den Sinn. Bei der ACL-Unterstützung von rsync scheint wohl das letzte Wort noch nicht gesprochen zu sein, wenn ich mir dies hier (gerade aus Zeitmangel nur sehr flüchtig) anschaue. Vielleicht gibt's da ja noch eine Spur?