Unison sync tra Windows/Linux si blocca casualmente durante il trasferimento

Question

Distribuiamo regolarmente CPU del chiosco interattivo a siti phsyical remoti e ho sviluppato un'applicazione di aggiornamento del contenuto che esegue una sincronizzazione notturna delle risorse multimediali tra ciascun chiosco (Windows 7 Pro) e un CMS ospitato (server Ubuntu virtualizzato in esecuzione su linode.com). Il programma di aggiornamento del contenuto è creato in C# /. NET e genera un processo Unison secondario utilizzando Process.Start(). Unison è configurato per connettersi al server remoto tramite SSH utilizzando una chiave privata.

Il problema che stiamo colpendo è che quando generato come un processo figlio da ContentUpdater.exe, Unison spesso smette semplicemente di comunicare con il server remoto durante un trasferimento e si blocca indefinitamente. Non c'è una semplice riproduzione - a volte funziona, il più delle volte si blocca. Sembra essere più fragile su aggiornamenti più grandi (400 MB +), ma è più una congettura che altro. Quando si blocca, il processo Unison sul client (Windows 7) mostra ancora il 25% di utilizzo della CPU, e il server mostra anche il processo unison in esecuzione - non c'è solo attività di rete. So che si sta connettendo, perché inizia sempre il processo e passa attraverso il trasferimento, ma non si blocca mai nello stesso posto due volte. Sto eseguendo un build binario nativo di Windows di Unison-2.40.63.exe e la stessa versione di unison sul server remoto.

La riga di comando Unison su Windows appare come:

Unison-2.40.63.exe -contactquietly -silent -batch -sshcmd "C:\KioskManagement\Apps\ssh2plink.bat" -sshargs "-p 22 -i C:\cygwin\home\someuser\.ssh\contentupdater-rsync-key.ppk" -ignore "Path {innovations,todaytomorrow,scale,mooreslaw,brilliantminds,askafab}" ssh://cmsuser@server//home/cms/base-preview/webapps/ROOT/applications C:\kioskdir\temp\applications -force ssh://cmsuser@server//home/cms/base-preview/webapps/ROOT/applications 

Per la cronaca, avevo inizialmente scritto il programma di aggiornamento dei contenuti da utilizzare rsync (via Cygwin su Windows), ma stava colpendo gli stessi problemi. Per vedere se il trasporto ssh era parte del problema, I tried using rsync in server mode (rsyncd) ma l'impiccagione continuava a far girare la testa.

A questo punto, sono completamente sconcertato. Il problema si ripropone anche su altri server, quindi penso che sia sul lato Windows delle cose. Sono anche incline a credere che il problema si verifica solo quando si chiama Unison/rsync da Process.Start() all'interno di un altro processo (UPDATE: ho appena ricevuto la repro quando si esegue dalla riga di comando) - non sembra fallire quando si esegue direttamente dalla riga di comando. Unison/rsync non sbaglia mai, quindi non ci sono file di log da controllare (a meno che qualcuno non conosca una sorta di traccia sul lato server o file di log sul server remoto che posso controllare - rivelazione completa: sono un fanatico di FreeBSD, e so prezioso poco di Ubuntu sotto il cofano).

Grazie in anticipo per qualsiasi intuizione/idee/soluzioni!

Best

Answer 1

Solo rintocchi; Ho lo stesso problema con rsync/cygwin tra due computer Windows 7. Le discussioni più vecchie sulla rete suggerivano che il problema riguardava solo le connessioni ssh, ma il metodo daemon rsync fallisce per me. Ci sono messaggi che fingono che si dovrebbe ricompilare rsync dall'origine che blocca HAVE_SOCKETPAIR, che si dice che faccia funzionare rsync/ssh. Non sono riuscito a provarlo.

Answer 2

Ho avuto questo problema. Mi ci sono voluti diversi giorni per risolverlo. Terminato che l'aggiunta -halfduplex ha risolto il mio problema.

Come indicato nella documentazione:

halfduplex Quando questo flag è impostato su true, la comunicazione di rete Unison è costretto ad essere half duplex (il client e il server non emettere simultaneamente i dati). Se riscontri problemi di instabilità con il tuo collegamento di rete, questo può essere d'aiuto. La comunicazione è sempre half-duplex durante la sincronizzazione con un computer Windows a causa di una limitazione dell'implementazione corrente Unison che potrebbe provocare un deadlock.

Nel mio caso, stavo sincronizzando tra Windows/OSX.

Answer 3

Confermo che l'impostazione "halfduplex = true" ha risolto i problemi di sospensione. Avevo impostato i "client" Win7 e OSX e il server Linux come punto di sincronizzazione centrale. Tutto il client si sincronizza con il server.

I problemi sono iniziati quando ho introdotto il client Mac sull'immagine da allora gli aggiornamenti hanno iniziato a verificarsi in entrambe le direzioni. L'impostazione "halfduplex = true" nel profilo Unison ha risolto il mio problema.

Stranamente, Unison ha sincronizzato tutto una directory molto più piccola tra due client Win7 e il server Linux, ma in questo caso i file sono molto più piccoli.