La synchronisation à l'unisson entre Windows et Linux se bloque pendant le transfert

Question

Nous déployons régulièrement des processeurs de kiosques interactifs sur des sites distants et j'ai développé une application de mise à jour de contenu qui effectue une synchronisation nocturne des ressources multimédias entre chaque kiosque (Windows 7 Pro) et un CMS hébergé (serveur Ubuntu virtualisé tournant sur linode.com). Le programme de mise à jour de contenu est créé dans C#/.NET et génère un processus Unison enfant à l'aide de Process.Start(). Unison est configuré pour se connecter au serveur distant via SSH à l'aide d'une clé privée. Le problème que nous rencontrons est que lorsqu'il est engendré en tant que processus fils à partir de ContentUpdater.exe, Unison arrête souvent simplement de communiquer avec le serveur distant pendant un transfert et se bloque indéfiniment. Il n'y a pas de repro simple - parfois cela fonctionne, plus souvent qu'autrement, il se bloque. Il semble être plus fragile sur les plus grosses mises à jour (400MB +) mais c'est plus de conjecture qu'autre chose. Quand il se bloque, le processus Unison sur le client (Windows 7) montre toujours 25% d'utilisation du processeur, et le serveur montre également le processus unisson en cours d'exécution - il n'y a juste pas d'activité réseau. Je sais que c'est en train de se connecter, parce que cela commence toujours le processus et passe à travers le transfert, mais il ne reste jamais deux fois au même endroit. J'utilise une version binaire Windows native de Unison-2.40.63.exe et la même version d'unison sur le serveur distant.

La ligne de commande Unison sous Windows ressemble:

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 

Pour mémoire, j'avais initialement écrit Updater de contenu à utiliser rsync (via Cygwin sous Windows), mais frappait les mêmes problèmes. Pour voir si le transport de SSH faisait partie du problème, j'ai continué à élever la tête.

À ce stade, je suis complètement perplexe. Le problème se répercute également sur d'autres serveurs, donc je pense que c'est du côté Windows. Je suis également enclin à croire que le problème se produit uniquement lors de l'appel Unison/rsync de Process.Start() à l'intérieur d'un autre processus (UPDATE: Je l'ai juste à repro lors de l'exécution de la ligne de commande) - il ne semble pas échoue lors de l'exécution directement à partir de la ligne de commande. Unison/rsync aussi jamais d'erreur, donc il n'y a pas de fichiers journaux à vérifier (à moins que quelqu'un connaisse une sorte de trace côté serveur ou fichier journal sur le serveur distant, je peux vérifier - divulgation complète: je suis un geek de FreeBSD précieux peu sur Ubuntu sous le capot).

Merci d'avance pour toutes les idées/idées/solutions!

Meilleur

Answer 1

Just chiming in; J'ai le même problème en utilisant rsync/cygwin entre deux ordinateurs Windows 7. Des discussions plus anciennes sur le réseau ont suggéré que le problème n'affectait que les connexions ssh, mais la méthode du démon rsync échouait pour moi. Il y a des messages prétendant que l'on devrait recompiler rsync de la suppression de la source HAVE_SOCKETPAIR, qui est dit pour faire fonctionner rsync/ssh. Je n'ai pas eu l'occasion d'essayer ça.

Answer 2

J'ai eu ce problème. Ça m'a pris plusieurs jours pour le résoudre. Terminé que l'ajout-halfduplex a résolu mon problème.

Comme il est indiqué dans la documentation:

halfduplex Lorsque cet indicateur est défini sur true, la communication réseau Unison est forcé d'être semi-duplex (le client et le serveur n'émettent simultanément des données). Si vous rencontrez des déséquilibres avec votre lien réseau, cela peut aider. La communication est toujours semi-duplex lors de la synchronisation avec une machine Windows en raison d'une limitation de l'implémentation actuelle de Unison pouvant entraîner un blocage.

Dans mon cas, je synchronisais entre Windows/OSX.

Answer 3

Je confirme que le paramètre "halfduplex = true" a résolu mes problèmes d'accrochage. J'ai eu la configuration de Win7 et OSX "clients" et le serveur Linux comme point de synchronisation central. Tous les clients se synchronisent avec le serveur.

Les problèmes ont commencé lorsque j'ai présenté le client Mac à l'image depuis que les mises à jour ont commencé à se produire dans les deux directions. La définition de "halfduplex = true" dans le profil Unison a résolu mon problème. Bizarrement, Unison synchronisé tout bien un répertoire beaucoup plus petit entre deux clients Win7 et le serveur Linux, mais les fichiers sont beaucoup plus petits dans ce cas.