LINBO: Synchronisierter Start scheitert

[Michael]

Hallo.
Ich wurde heute Morgen in einen Computerraum mit 16 Clients gerufen, um mir den Start der Clients anzusehen. Der Workaround von Dorian war zu dem Zeitpunkt noch nicht eingestellt, so dass die Clients also alle synchronisiert gestartet sind. Nun war es so, dass trotzdem nicht alle Clients zuverlässig hochfahren konnten. Bei 3 der Clients erschien zunächst der LINBO-Bildschirm inkl. richtiger IP-Adresse. Danach sollte der Sync automatisch starten, doch stattendessen erschien „Failed to mount partition“. Ich habe extra nochmal mit F1 nachgesehen: Sowohl die Festplatte wurde erkannt als auch der Cache richtig angezeigt. Dennoch konnte der Sync nicht starten!
Und dann die Überraschung: Neustart – alles lief fehlerfrei durch und die Synchronisation funktionierte wie immer. Woran kann das liegen?

Im Anhang die Log-Datei, die anschließend auf den Server hochgeladen wurde … ich meine, dass das einer der Clients war, der zunächst nicht wollte…
raum1.doc (37,7 KB)
(ist eine .log-Datei – musste ich aber umbenennen, um sie hochladen zu können)

Viele Grüße,
Michael

[Michael]

Hallo.
Ich glaube, dass ich die Ursache gefunden habe … und ich glaube, dass das ein Feature von rsync / LINBO ist, dass so eigentlich nicht gewollt ist?!?
Das Problem scheint zu sein, dass das cloop per Rsync übertragen wird und zunächst .fossa.<irgendeineID> heißt. Wenn dieser Prozess aus irgendeinem Grund fehlschlägt oder nicht zu Ende durchläuft, bleibt diese Datei erhalten und wird nicht automatisch gelöscht. Das bedeutet, dass der Cache bei mehrfachen (gescheiterten!) Synchronisationen irgendwann vollgelaufen ist und somit der nächste Sync.Start nicht mehr funktioniert, wenn ein neues Image heruntergeladen werden soll. Daher wäre meine Frage: Kann man es LINBO beibringen, die alten/unvollständigen .fossa.<irgendeineID>-Cloops automatisch zu löschen, bevor eine neuer Download beginnt?
Es scheint ein rsync-only-Problem zu sein, oder?

Viele Grüße,
Michael