小编hur*_*n77的帖子

在一台 linux 服务器（Gentoo 强化）上，我们不时在 dmesg 中遇到以下消息的爆发：

TCP: Treason uncloaked! Peer xx.xx.xxx.xxx:65039/80 shrinks window 4094157295:4094160199. Repaired.

有什么我们应该注意的吗，或者这是正常的吗？

更新：也许相关，我们正在使用net.ipv4.tcp_congestion_control = cubic. 内核版本为 2.6.28，带有 Gentoo 强化补丁。

更新：这可能真的与硬件/驱动程序问题有关，因为我们有时会在交换机上看到“hickup”：端口关闭并再次出现。直到最近我们才发现以下与这些端口故障相关的 dmesg 输出：

[5781269.910133] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[5781269.910136]   Tx Queue             <0>
[5781269.910137]   TDH                  <e0>
[5781269.910139]   TDT                  <76>
[5781269.910140]   next_to_use          <76>
[5781269.910141]   next_to_clean        <da>
[5781269.910143] buffer_info[next_to_clean]
[5781269.910144]   time_stamp           <22750e54>
[5781269.910146]   next_to_watch        <e2>
[5781269.910147]   jiffies              <22750f5f>
[5781269.910148]   next_to_watch.status <0>

通常在这些记录的行之后还有一些“Treason uncloaked”行（但反之亦然，这意味着这些行并不总是在“Treason uncloaked”之前记录）。

以 django-9999 ebuild 为例，为了匹配开发人员的环境，我需要从主干中检出 R12120。由于包管理的原因，手动安装 Django 不是一个选项。但是对于 1.2 测试版，portage 中也没有 ebuild。

所以我做了以下事情：

ESVN_OPTIONS="-r12120" emerge -1a django

其中从 svn 安装了所需的修订版。但这在某种程度上很麻烦。是否有某种方法可以为每个 ebuild 静态定义它，例如：

DJANGO_SVN_REV="12120"

在make.conf。这在我眼里会干净得多。

因为下次无论出于何种原因我需要重建 django 时，我需要记住：“哦，我希望它坚持特定的修订版”，下一个问题将是“错误，f&！#$？％，又是什么？”

去这里的最佳方式是什么？

记住：

• 在没有包管理器知识的情况下手动安装包是没有选择的
• 解决手动emerge变量前缀是没有选择的
• 设置 /etc/portage/package.env 将是一种方法（如此处所述），但这对我来说似乎非常不受支持且笨拙，因此不可取
• 修改 make.conf 将是一种方法
• 将 ebuild 保留在覆盖层中将是一种选择

当 PHP 在 Apache 中执行时，我们的一台旧式服务器没有进一步更新或重新配置，突然停止将主机名解析为 IP。但是，从 CLI 执行时它仍然可以正常工作。

从 RSS 缓存上次修改时间，我推断它在 3 月 28 日左右停止工作。

为了重现这个问题，我创建了一个脚本fsockopen()，上面写着“连接失败（错误号 2）”。我进一步将问题归结为与失败的名称解析有关：

<?php $addr = gethostbyname("twitter.com"); echo "ADDR($addr)"; ?>

当我通过 Apache 运行它时，输出是ADDR(twitter.com)，这是错误的。

当我从 CLI 运行它时，输出ADDR(aaa.bbb.ccc.ddd)具有不同的 IP 地址，正如预期的那样。

服务器设置上的任何内容都没有改变。CLI 和 Apache 模块共享相同的php.ini. PHP 是带有 Zend Optimizer v2.5.10 的 v4.4.9 版本。Apache 是 v1.3.31。

我知道这些版本是旧的。但是由于没有任何改变，像“先尝试升级版本”这样的解决方案是行不通的，因为服务器的功能集/版本控制被冻结并且很快就会被替换。我们仍然需要一个解决方案。

如果我运行dig脚本，它可以在两种环境（mod_php 和 CLI）中工作，但这不仅仅是一个丑陋的黑客，因为它会涉及整个脚本库中的许多编辑和测试，这也是不受欢迎的，因为服务器上的 PHP 应用程序是也被冻结，并且只接收安全更新。它将被完全重写（在新服务器上）所取代。

但是由于重写需要一些时间并连续替换遗留应用程序的部分，我们需要修复解析器问题。我已经用谷歌搜索了一下，虽然问题是已知的，但许多人没有找到解决办法。提高内存限制的修复不起作用。重新启动没有用。mod_php 中的解析器确实没有明显原因停止工作。:-(

更新：我同时通过完全停止 apache 来解决它，等待片刻，然后再次启动它。但这并不能解释这种行为的根本原因（因此没有令人满意的解决方案）。所以我把它打开。