在“将文件复制到丢弃位置”步骤后诊断TFS构建挂起

时间：2014-02-03 22:09:24

标签： tfs tfsbuild tfs2013

我需要一些关于如何诊断悬挂构建的建议。这只发生在过去一两周，我有充分的理由怀疑这是我最近做过的事情而不仅仅是巧合

设置

  • TFS 2013
  • 4台机器设置 - 2个应用程序层（在弃用其中一个的过程中），1个sql server，1个运行2个代理的构建服务器。
  • Build Controller与作业代理
    • 一起在第二个应用层上运行
  • 第一个应用程序层正在为网站提供服务（虽然该机器将很快关闭，并且随着机器老化，所有内容都将传递到第二个应用程序层）

症状

  • 所有已执行的构建（似乎与哪个构建过程模板无关）永远不会标记为已完成，最后一步似乎始终是“将文件复制到删除位置”/“工作区和复制文件到删除位置” “/”复制二进制文件以删除，重置环境“（在每个构建模板中命名不同）
  • 文件似乎在构建投放文件夹
    • 中成功删除
  • 查看任务管理器，似乎退出构建服务器上的所有构建过程（仅限TFSBuildServiceHost
  • 构建在执行
    • 时显示正常步骤/日志记录
  • 主要应用层在事件日志中有相关警告（请参阅下面的警告）

最近的更改

  • 在构建服务器上安装Xamarin Android / iOS
  • 为Job Agent，Message Queue和Web Services安装了一些自定义插件（多年来一直使用它们，因为应用层迁移导致它们在过去几周被禁用）
  • 安装了Tiago的任务板增强器（再次使用它很长一段时间，最近才禁用它）
  • 大约一个月前，我们添加了第二个应用层并将sql移到另一台机器上

我尝试过什么

  • 重新启动应用程序层并构建服务器
  • 卸载Xamarin（虽然我怀疑某些部件仍在浮动，因为Bonjour服务似乎仍然安装）
  • 删除自定义插件
  • 在其中一个版本上启用了日志记录诊断功能 - 似乎没有任何特别感兴趣
  • 运行最佳实践分析器（没有太多不寻常的显示）
  • 多个构建过程模板（defaulttemplate，defaulttemplate.11.1，tfvctemplate.12.xaml）
  • 多个构建定义
  • 检查了AppTiers和Build server的事件日志
  

Team Foundation服务主机请求监视器已检测到   以下条件：日期（UTC）：3/02/2014 12:54:06 a.m. Machine：   CODEBASE应用领域：/ LM / W3SVC / 1 / ROOT / tfs-1-130357641583538280   程序集：Microsoft.TeamFoundation.Framework.Server，Version = 12.0.0.0，   Culture = neutral，PublicKeyToken = b03f5f7f11d50a3a; v4.0.30319服务   主持人：0dc282b5-59a8-4941-b541-a4f7d314cd0f工艺细节：流程   名称：w3wp进程ID：2508线程ID：2504

     

详细消息：服务主机XXXX的请求一直在执行   持续37秒，超过警告阈值30。       请求详情：请求上下文详细信息       网址：/ tfs / XXXX / XXXX / _api / _build / stop？__ v = 4       方法：ApiBuild.stop       参数：uri = vstfs：/// Build / Build / 34064       用户代理：Mozilla / 5.0（Windows NT 6.2; WOW64）AppleWebKit / 537.36（KHTML，如Gecko）Chrome / 32.0.1700.102 Safari / 537.36       唯一ID：00000000-0000-0000-0000-000000000000

     

Team Foundation服务主机请求监视器已检测到   以下条件：日期（UTC）：2014年1月30日下午11:10:01机：   CODEBASE应用领域：/ LM / W3SVC / 1 / ROOT / tfs-1-130355232548668648   程序集：Microsoft.TeamFoundation.Framework.Server，Version = 12.0.0.0，   Culture = neutral，PublicKeyToken = b03f5f7f11d50a3a; v4.0.30319服务   主持人：0dc282b5-59a8-4941-b541-a4f7d314cd0f工艺细节：流程   名称：w3wp处理ID：70320线程ID：14540

     

详细消息：服务主机XXXX的请求一直在执行   持续37秒，超过警告阈值30。       请求详情：请求上下文详细信息       网址：/tfs/XXXX/Build/v4.0/BuildService.asmx       方法：StopBuilds       参数：uris [0] = vstfs：/// Build / Build / 34051 uris = Count = 1       用户代理：Team Foundation（devenv.exe，12.0.21005.1，Premium，SKU：16）       唯一ID：4d2d3213-fd41-4c4d-8ab0-b87619c96a42

     

Team Foundation服务主机请求监视器已检测到   以下条件：日期（UTC）：31/01/2014 3:14:17 a.m.机器：   CODEBASE应用领域：/ LM / W3SVC / 1 / ROOT / tfs-1-130355232548668648   程序集：Microsoft.TeamFoundation.Framework.Server，Version = 12.0.0.0，   Culture = neutral，PublicKeyToken = b03f5f7f11d50a3a; v4.0.30319服务   主持人：流程细节：流程名称：w3wp流程ID：70320
  主题ID：14540

     

详细消息：服务主机XXXX没有活动请求   超过警告阈值30。

一个快速的谷歌建议在tfs注册表中加快超时（http://xavierdilipkumar.com/post/2013/07/04/TFS-event-7005-and-7006-warning.aspx）我已经尝试过了，它似乎没有改变任何东西。

7 个答案:

答案 0 :(得分：3)

你可以查看

中的tfs bs日志吗？ 
Event Viewer -> Applications and Services Logs -> Microsoft -> Team Foundation Server -> Build-Services -> Operational

这些超时通常与权限有关。你应该寻找TF215106访问被拒绝事件。虽然文件似乎在那里，但它们都是当前日期还是有一些具有不同（较旧）的日期？当文件丢失时，它们也会发生任何警报/步骤吗？

除此之外，它可能会超时，因为其中一个依赖项正被其他服务使用。

答案 1 :(得分：2)

您可以启动Sysinternals Process Monitor以查看进程实际退出的时间以及它们正在执行的操作（Process Monitor监视“实时文件系统，注册表和进程/线程活动”）。

答案 2 :(得分：1)

最佳操作方法是致电Microsoft支持并打开服务请求。确保它获得优先级A - 您的TFS生产环境不起作用 - 并准备好为他们提供支持和访问。

日志中唯一的提示是调用 ApiBuild.stop 。它表明构建工作流程已完成，因此托管它的代码正在回调AT以标记构建完成。由于之前的调用没有警告，因此在数据库级别可能存在一些问题。您可以尝试激活SQL跟踪，但这不是一项简单的任务，因为您应该能够将跟踪与工作跟踪进行比较。

祝你好运

答案 3 :(得分：1)

我不愿意将此标记为答案，因为我不完全确定它为何有效。

怀疑构建机器出了问题我在新安装时创建了一个新的构建代理 - 挂起的问题仍然存在。

然后我在该机器上添加了一个Build Controller，并注意到使用该控制器的新版本将完成。这表明BA和BC之间或BA和主要AT之间存在沟通问题。

鉴于我们的主要AT有其他问题，我们决定将其从图片中删除，我们将DNS切换到指向第二个AT，并禁用旧主服务器上的所有服务。即时构建开始完成（包括已经停留数天的那些）。

我仍然不知道哪个组件被破坏或者为什么，特别是因为它在此配置中运行了一个月之前。我只能假设还有另一个我不知道的变化，或者主要AT的腐败导致了更大的问题。

答案 4 :(得分：1)

我们在这里遇到了同样的问题，即使在成功通过所有工作流程阶段之后，构建仍保持打开状态。

我登录到构建机器并注意到构建控制器由于某种原因“正在运行6个构建”，即使Visual Studio中的队列中根本没有构建。

重新启动控制器后，下一次构建第一次工作。

我想在这里作为一个可能的答案。我不确定为什么控制器会有那些卡住的版本。

答案 5 :(得分：0)

当一个活动试图在构建日志中记录一条巨大的消息（即CodePlex TFS Build Extensions项目中的FxCopCmd活动）时，我遇到了这个问题。

构建代理将成功完成构建，但控制器必须将巨大的消息咀嚼到构建日志中，并且它正在静默崩溃/挂起。

我能够通过导航到C:\Users\[TfsServiceAccount]\AppData\Local\Temp\BuildAgent\[AgentNumber]\Logs\[BuildNumber]\ActivityLog.xml来跟踪问题。

最后一个构建消息被截断，通过查看内容，我认识到了FxCop输出。在我的例子中，我只是为构建过程模板中的FxCop活动将LogToConsole参数设置为False，并且构建成功完成。

答案 6 :(得分：0)

如果构建代理无法连接到端口9191上的构建控制器服务器，也会出现这种情况。

使用telnet客户端轻松测试。

看来我的服务器认为它是在一个未知的网络上并将防火墙踢入了高速模式。 （我第二次遇到这个问题，不确定这是否是我第一次得到它的原因，但这似乎是合理的。）

相关问题
最新问题