.net - Unison synkronisering mellem Windows/Linux hænger tilfældigt under overførsel

Indlæg af Hanne Mølgaard Plasc

Problem



Vi implementerer jævnligt interaktive kiosk-CPU'er til eksterne phsyical sites, og jeg har udviklet et indholds opdateringsprogram, der udfører en natlig synkronisering af medieaktiver mellem hver kiosk (Windows 7 Pro) og en hostet CMS (virtualiseret Ubuntu-server, der kører på linode.com) Content Updater er forfattet i C #/.NET, og det gyder en Unison-proces med Process.Start (). Unison er konfigureret til at oprette forbindelse til den eksterne server via SSH ved hjælp af en privat nøgle.


Problemet, som vi rammer, er, at Unison ofte vil stoppe med at kommunikere med den eksterne server under en overførsel og hænge på ubestemt tid, når det er skabt som en børneproces fra ContentUpdater.exe. Der er ingen simpel repro - nogle gange virker det ofte end ikke det hænger. Det ser ud til at være mere skrøbeligt på større opdateringer (400MB +), men det er mere formodning end noget andet. Når det hænger, viser Unison-processen på klienten (Windows 7) stadig 25\% CPU-udnyttelse, og serveren viser også Unison-processen kører også - der er bare ingen netværksaktivitet. Jeg ved, at det er tilsluttet, fordi det altid starter processen og bliver delvist gennem overførslen, men det hænger aldrig på samme sted to gange. Jeg kører en indbygget Windows binær build af Unison-2.40.63.exe og den samme version af unison på fjernserveren.


Kommandolinjen Unison på Windows ligner:


Unison-2.40.63.exe -contactquietly -silent -batch -sshcmd "C:KioskManagementAppsssh2plink.bat" -sshargs "-p 22 -i C:cygwinhomesomeuser.sshcontentupdater-rsync-key.ppk" -ignore "Path {innovations,todaytomorrow,scale,mooreslaw,brilliantminds,askafab}" ssh://cmsuser@server//home/cms/base-preview/webapps/ROOT/applications C:kioskdir	empapplications -force ssh://cmsuser@server//home/cms/base-preview/webapps/ROOT/applications


For posten havde jeg oprindeligt skrevet indholds opdaterer til at bruge rsync (via cygwin på Windows), men ramte de samme problemer. For at se, om ssh-transporten var en del af problemet, forsøgte jeg at bruge rsync i server-tilstand (rsyncd), men den hængende fortsatte med at bære hovedet. [2]


På dette tidspunkt er jeg grundigt stumpet. Problemet repros på andre servere, så jeg tænker på det på Windows side af ting. Jeg er også tilbøjelig til at tro på, at problemet kun sker, når man kalder Unison/rsync fra Process.Start () inde i en anden proces (UPDATE: Jeg har lige fået det til at repro når du kører fra kommandolinjen) - det synes ikke at mislykkes, når du kører direkte fra kommandolinjen. Unison/rsync også aldrig fejl, så der er ingen logfiler at kontrollere (medmindre nogen ved en slags server-side spor eller logfil på fjernserveren jeg kan tjekke - fuld offentliggørelse: Jeg er fri for FreeBSD-geek og kender værdifulde lidt om Ubuntu under emhætten).


På forhånd tak for alt indsigt/ideer/løsninger!


Bedst

Bedste reference


Jeg havde dette problem. Tog mig flere dage for at løse det.
Afsluttet, at tilføje -halfduplex løste mit problem.


Som angivet i dokumentationen:


halfduplex
Når dette flag er sat til sandt, er Unison netværkskommunikation tvunget til at være halv duplex (klienten og serveren sender aldrig data samtidigt). Hvis du oplever ustabilitet med dit netværkskæde, kan det være en hjælp. Kommunikationen er altid halvduplex, når den synkroniseres med en Windows-maskine på grund af en begrænsning af Unisons nuværende implementering, der kan resultere i en deadlock.


I mit tilfælde synkroniserede jeg mellem Windows/OSX.

Andre referencer 1


Jeg bekræfter at indstillingen 'halfduplex=true' har løst mine hængende problemer. Jeg havde setup af Win7 og OSX 'klienter' og Linux server som centralt synkroniseringspunkt. Alle klienter synkroniseres med serveren.


Problemerne startede, da jeg introducerede Mac-klienten på billedet, siden opdateringer begyndte at ske med begge retninger. Indstilling af 'halfduplex=true' i Unison-profil løst mit problem.


Alligevel synkroniserede Unison alle fint en meget mindre mappe mellem to Win7-klienter og Linux-serveren, men filerne er meget mindre i det tilfælde.

Andre referencer 2


Bare chiming i; Jeg har det samme problem ved at bruge rsync/cygwin mellem to Windows 7-computere. Ældre diskussioner på nettet foreslog, at problemet kun berørte ssh-forbindelser, men rsync daemon-metoden mislykkes for mig. Der er meddelelser som foregiver at man skal genopbygge rsync fra source unsetting HAVE\_SOCKETPAIR, der siges at gøre rsync/ssh arbejde. Jeg har ikke gået rundt for at prøve det.