脚本头过早结束：php5 Symfony 产生内部服务器错误 500答案

【问题标题】：Premature end of script headers: php5 Symfony produces internal server error 500脚本头过早结束：php5 Symfony 产生内部服务器错误 500
【发布时间】：2011-04-05 07:53:39
【问题描述】：

我遇到了一个让我陷入死胡同的问题，所以反过来，我求助于你！最近，一个 Symfony 应用程序出现故障，呈现内部 apache 错误 -500。删除 Symfony 缓存后，站点会恢复。经过进一步调查，我发现“脚本头过早结束：php5”的错误。该网站在 1 年多的时间里没有出现任何类似的错误，我们也没有对这个网站进行任何更改，而且这种情况经常发生（每周一次）。以下来自日志文件。

[Sat Aug 28 06:20:30 2010] [error] [client 206.131.184.1] Premature end of script headers: php5

这封电子邮件也是最近从 MT 发送的，可能与我认为可能与问题直接相关。

我们注意到您的服务 ----.com 在托管您帐户的集群上生成了大量的文件系统锁。错误地使用 NFS 文件锁定的网站或脚本通常会生成此错误，这会严重影响其他客户的集群性能。这违反了我们的 AUP，可以在“http://mediatemple.net/company/legal/aup_general.php”找到。

我们跟踪到以下文件的文件锁定问题，该文件被反复锁定：

/domains/----.com/symfony/cache/frontend/prod/config/routing/symfony.routing.configuration.cache /domains/----.com/symfony/cache/frontend/prod/config/routing/symfony.routing.data.cache

如果选项可用（通常位于脚本的配置部分），我们建议您立即禁用脚本的文件锁定；或使用不使用文件锁定的其他脚本。此脚本将来滥用锁定可能会导致此域的流量暂停，以防止锁定影响其他客户。

如果您对此文件锁定问题有任何疑问，或者不确定从何处开始禁用文件锁定，请回复此票证以获得进一步帮助。

【问题讨论】：

标签： php apache symfony1 mediatemple

【解决方案1】：

仅当您使用 Google Chrome 浏览并抛出异常时才会发生这种情况。在 Monolog 的一些变化中，他们启用了“chromephp”。

在您的 config_dev.yml 中：

monolog:
handlers:
    main:
        type:  stream
        path:  %kernel.logs_dir%/%kernel.environment%.log
        level: debug
    firephp:
        type:  firephp
        level: info
    chromephp:
        type:  chromephp
        level: info

删除整个 chromephp 块，一切正常。

【讨论】：

这个答案与这个问题无关。这是一个 symfony 问题，不是独白——考虑修改它。
答案与本题无关？你知道 Symfony 吗？ Monolog 是 symfony 自带的默认 bundle，所以当然是相关的！
但是这个问题是在技术上是 sf1，而不是 Symfony2。但是 Symfony 1 很古老，我发现了这个问题，它解决了我的问题，所以想
@mYkon - 伙计 - 这个答案与问题无关；）*但你刚刚拯救了我的一天！ Tnx！

【解决方案2】：

我认为在方法 read() 中禁用 Symfony 的缓存锁定以读取 lib/cache/sfFileCache.class.php 是安全的。 Symfony 在阅读时使用共享锁。锁不是必需的，因为 Symfony 使用临时文件并在写入时重命名。此外，在lib/log/sfFileLogger.class.php 中，doLog() 方法中的锁定不是必需的，因为写入是原子的（单个 fwrite() 调用），并且文件以附加模式打开。

我还没有测试过这些更改会如何影响 Symfony。

“脚本头过早结束”不是 PHP 错误消息。当后端（本例中为 PHP）不发送标头时，Web 服务器会发出此消息。这很可能是因为它在它能够做任何事情之前就死了。您应该找到 PHP 错误日志并查看真正的错误消息。但是请注意，Symfony 在函数调用中使用了大量的@ 来抑制错误，因此您可能找不到任何东西。

【讨论】：

谢谢，我希望这与@kuba 的信息一致，我们应该没问题。
jmz +1 为您提供帮助。我确实解决了这个问题，并且不再有文件锁定，但我不认为这是主要问题的根源。它肯定有助于解决问题的次要部分，但 sfFileCache 是罪魁祸首。再次感谢！

【解决方案3】：

最近我遇到了类似的问题。用 APC 替换文件缓存完全解决了我的问题。我需要将 sfFileCache 替换为 view_cache、i18n 缓存和路由。

如果 APC 在您的服务器上不可用，那么您可以轻松地使用任何其他流行的加速器来代替。

如何在 symfony 中使用 APC：http://www.zalas.eu/symfony-meets-apc-alternative-php-cache

【讨论】：

感谢 @kuba 我刚刚实施的洞察力，并希望取得最好的结果。
如果有帮助别忘了写 ;)
一段时间后，该站点似乎运行良好，并且成功了。太感谢了！！抱歉耽搁了，我想确保网站已解决。