2012-03-19 119 views
5

我們經常將交互式自助終端CPU部署到遠程物理站點,並且我開發了一個內容更新應用程序,在每個自助服務終端(Windows 7 Pro)和託管CMS(在linode.com上運行的虛擬化Ubuntu服務器)。內容更新程序以C#/ .NET編寫,並使用Process.Start()生成一個Unison子進程。 Unison配置爲使用私鑰通過SSH連接到遠程服務器。Windows/Linux之間的同步同步在傳輸過程中隨機掛起

我們碰到的問題是,當從ContentUpdater.exe生成子進程時,Unison通常會在傳輸過程中停止與遠程服務器的通信並無限期地掛起。沒有簡單的再生產 - 有時它可以工作,通常不會掛起。在較大的更新(400MB +)上似乎更脆弱,但這比其他任何更多的猜測。當它掛起時,客戶端(Windows 7)上的Unison進程仍顯示25%的CPU利用率,並且服務器還顯示正在運行的unison進程 - 沒有網絡活動。我知道它是連接的,因爲它總是啓動過程並在轉移過程中取得成功,但它永遠不會在同一個地方掛兩次。我正在運行Unison-2.40.63.exe的本地Windows二進制版本,以及遠程服務器上的同一版本的unison。

在Windows同音命令行的樣子:

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://[email protected]//home/cms/base-preview/webapps/ROOT/applications C:\kioskdir\temp\applications -force ssh://[email protected]//home/cms/base-preview/webapps/ROOT/applications 

爲了記錄在案,我原本撰寫了內容更新到(在Windows上通過Cygwin)使用rsync,但被擊中了同樣的問題。要看看ssh運輸是否是問題的一部分,我tried using rsync in server mode (rsyncd)但懸掛繼續後面的頭。

在這一點上,我徹底難倒了。這個問題也在其他服務器上重演,所以我認爲它在Windows的一面。我也傾向於認爲只有在從另一個進程(更新:我剛從命令行運行時纔得到repro)調用Unison/rsync從Process.Start()調用時纔會出現問題 - 它似乎並不從命令行直接運行時失敗。 Unison/rsync也不會出錯,所以沒有日誌文件可以檢查(除非有人知道我可以檢查遠程服務器上的某種服務器端跟蹤或日誌文件) - 完全公開:我是FreeBSD極客,並且知道引擎蓋下的Ubuntu很少)。

在此先感謝您提供任何洞見/想法/解決方案!

最好

回答

1

只是在鳴;我在兩臺Windows 7計算機之間使用rsync/cygwin遇到同樣的問題。網上較舊的討論表明,該問題僅影響SSH連接,但rsync守護進程方法失敗。有消息假裝應該重新編譯rsync來源,取消設置HAVE_SOCKETPAIR,也就是說讓rsync/ssh工作。我還沒有到處去嘗試。

+0

這似乎不是一個答案。 – 2012-10-19 20:58:12

6

我有這個問題。花了我好幾天的時間來解決它。 最後,加入-halfduplex解決了我的問題。

如文檔中所述:

半雙工 當這個標誌被設置爲true,同音網絡通信被強制爲半雙工(客戶端和服務器從來不同時發射數據)。如果您的網絡鏈接不穩定,這可能會有所幫助。由於可能導致死鎖的Unison當前實現的侷限性,與Windows機器同步時,通信始終爲半雙工。

就我而言,我是在Windows/OSX之間進行同步。

3

我確認「halfduplex = true」設置解決了我懸置的問題。我設置了Win7和OSX「客戶端」和Linux服務器作爲中央同步點。所有客戶端都與服務器同步。

當我將Mac客戶端引入圖片後開始出現問題,此後更新開始發生在兩個方向。在Unison配置文件中設置「halfduplex = true」解決了我的問題。

奇怪的是,Unison在兩臺Win7客戶端和Linux服務器之間同步了一個小得多的目錄,但是在這種情況下文件要小得多。