Trac系统，mod_wsgi的，剧本的过早结束标头

当其中mod_wsgi的是守护进程的道路配置的服务器上运行Trac系统，Trac的抛出形式的许多错误：“脚本头过早结束”。我研究过这个，看起来Trac和Apache之间的expat库版本不匹配。可悲的是，我不能重建Apache，这似乎是解决这个问题的唯一解决方案。Trac系统，mod_wsgi的，剧本的过早结束标头

如果任何其他的解决方案是可能的，我不知道。当我以嵌入模式运行时，此问题消失。是否可以为在Trac请求中运行的虚拟主机配置为嵌入模式，而其他请求是否由配置为守护进程模式的主机处理？我们使用守护进程模式是因为Django项目，所以当代码改变时我们不必重启服务器。但我不知道以这种方式设置东西是否能解决问题，或者如果这样的设置甚至是可能的。

来源

2011-08-22 SixDegrees

以嵌入模式运行是不会解决问题。这个消息可能会消失，但是你的Apache子进程可能仍然崩溃，但是他们这样做可能不像主Apache错误日志显示'Segmentation fault'和其他东西那么明显。

当你说你看这个，你真的验证了它作为是通过运行记录在mod_wsgi的网站测试的外籍问题？

我问的外籍问题不是为什么Trac系统可能会崩溃的唯一原因。在子解释器中使用Python包装进行颠覆也会导致问题。所以，你试图设置的文件解决方法：

WSGIApplicationGroup %{GLOBAL}

有你走得更远，使用gdb作为地方上的mod_wsgi维基记录的代码会被再次崩溃分析。

至于你的Trac系统是否能在嵌入式和你的Django在守护进程模式下运行的问题，是可以做到，但我可以很可能会看到它没有解决的问题。

来源

2011-08-22 12:08:59

我还没有运行测试程序;当人们使用服务器时，我不能在白天做很多事情，所以必须等到明天。我确实证实了Apache使用的expat版本不同于Python使用的expat版本。我现在不在机器上，但是Apache使用类似1.5.x的东西，而Python使用2.0.x.奇怪的是，我们已经通过mod_wsgi在守护进程模式下运行了Django几个月，并且从未见过这个问题。它仅在我们将Trac添加到系统时才出现。我一直在嵌入式模式下运行，没有看到任何错误。 – SixDegrees

请注意，我几乎肯定没有时间在调试器中进行探索。如前所述，这些错误都是通过Trac发生的，而且是零星的;刷新页面通常会清除问题。但如果解决方案需要大量工时，抛弃Trac将可能成为首选解决方案。 – SixDegrees

我从http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary运行了您的测试应用程序;这两个例子，无论是否有expat，都能成功运行，所以显然expat就像这里的罪魁祸首一样。 – SixDegrees

Trac系统，mod_wsgi的，剧本的过早结束标头

回答

相关问题