我们遇到的问题是,当从ContentUpdater.exe作为子进程生成时,Unison通常会在传输过程中停止与远程服务器通信并无限期挂起.没有简单的复制品 – 有时候它会起作用,而不是它会挂起.它似乎在更大的更新(400MB)上更脆弱,但这比其他任何东西更令人猜测.当它挂起时,客户端上的Unison进程(Windows 7)仍然显示25%的cpu利用率,服务器也显示同步进程正在运行 – 没有网络活动.我知道它是连接的,因为它总是启动过程并在转移中途,但它永远不会挂在同一个地方两次.我正在运行Unison-2.40.63.exe的本机Windows二进制版本,以及远程服务器上的同一版本的unison.
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时(UPDATE:我从命令行运行时只是让它重新编译) – 它似乎没有直接从命令行运行时失败. Unison / rsync也永远不会出错,因此没有要检查的日志文件(除非有人知道我可以检查远程服务器上的某种服务器端跟踪或日志文件 – 完全披露:我是FreeBSD的极客,并且知道关于Ubuntu的一点点珍贵).
提前感谢所有见解/想法/解决方案!
最好
解决方法
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。