我们定期将交互式信息亭CPU部署到远程物理站点,并且我开发了一个内容更新程序,该应用程序在每个信息亭(Windows 7 Pro)和托管的CMS(在linode.com上运行的虚拟化Ubuntu服务器)之间执行媒体资源的每晚同步。 。内容更新程序是用C#/。NET编写的,它使用Process.Start()生成子Unison进程。 Unison配置为使用私钥通过SSH连接到远程服务器。

我们遇到的问题是,当从ContentUpdater.exe作为子进程生成时,Unison通常会在传输过程中简单地停止与远程服务器通信并无限期挂起。没有简单的复制方法-有时它可以正常工作,而经常挂起。在较大的更新(400MB +)上,它似乎更脆弱,但这比其他任何事情都容易引起猜想。挂起后,客户端(Windows 7)上的Unison进程仍显示25%的CPU利用率,服务器也显示统一进程正在运行-只是没有网络事件。我知道它正在连接,因为它总是启动进程并进入传输过程,但是它永远不会在同一位置挂两次。我正在运行Unison-2.40.63.exe的 native Windows二进制版本,并且在远程服务器上运行的是同一版本的统一。

Windows上的Unison命令行如下所示:

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

作为记录,我最初是创作内容更新程序以使用rsync的(在Windows上通过cygwin),但是遇到了同样的问题。要查看ssh传输是否是问题的一部分,我用tried using rsync in server mode (rsyncd)表示,但悬挂处继续抬起头。

在这一点上,我彻底陷入了困境。该问题也出现在其他服务器上,所以我认为这是Windows方面的问题。我也倾向于相信该问题仅在从另一个进程内部的Process.Start()调用Unison/rsync时才会发生(更新:从命令行运行时,我只是得到了repro的信息)-似乎没有直接从命令行运行时失败。 Unison/rsync也永远不会出错,因此没有要检查的日志文件(除非有人知道我可以检查的远程服务器上的某种服务器端跟踪或日志文件-完全公开:我是FreeBSD怪胎,并且知道关于Ubuntu的宝贵知识)。

在此先感谢您提供的所有见解/想法/解决方案!

最好的

最佳答案

我有这个问题。花了我几天时间解决。
结束了-halfduplex的添加解决了我的问题。

如文档中所述:

半双工
当此标志设置为true时,Unison网络通信将被强制为半双工(客户端和服务器永远不会同时发出数据)。如果您的网络链接不稳定,这可能会有所帮助。与Windows机器同步时,由于Unison当前实现的限制可能导致死锁,因此通信始终是半双工的。

就我而言,我在Windows/OSX之间进行同步。

关于.net - Windows/Linux之间的Unison同步在传输过程中随机挂起,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/9764504/

10-12 03:27