☰

Apache2/Shibboleth TCP 连接卡在 CLOSE_WAIT 状态

tag-icon • tag-icon apache-2.2 linux-networking shibboleth
Apache2/Shibboleth TCP 连接卡在 CLOSE_WAIT 状态

我运行一个 Apache2 服务器，该服务器使用 Shibboleth 守护进程 (shibd) 作为联合身份验证模块。某些使用 Shibboleth 的服务器连接似乎永久处于 CLOSE_WAIT 状态。

tcp       38      0 blah.blah:57346 shib.server.:8443 CLOSE_WAIT 
tcp       38      0 blah.blah:45601 shib.server2:8443 CLOSE_WAIT
tcp       38      0 blah.blah:41737 shib.server3:5057 CLOSE_WAIT

据我所知，CLOSE_WAIT 表示当远程服务器断开连接时，本地应用程序无法正常关闭连接。我怀疑 shibd 在某种程度上对此负有责任。

不用说，如果积累了足够多的 CLOSE_WAIT 连接，我就会遇到问题。

尝试通过使用以下方法摆脱 CLOSE_WAIT 连接

/etc/init.d/networking restart

不起作用。事实上，网络似乎拒绝关闭并重新启动，我收到 SIOCADDRT：文件存在错误（即网络试图在未先停止的情况下启动）。使用 ifup -a 时也存在同样的问题

所以我有两个问题——一个可能很容易，一个可能比较难。

  1. 有什么好方法可以强制重新启动网络，并强制清除卡在 CLOSE_WAIT 中的任何连接？
  2. 关于如何修复 shibboleth 并强制 shibd 模块正常运行，有什么想法吗？

答案1

不幸的是，1 的答案是重新启动仍然引用连接的进程。没有其他方法可以强制close他们这样做。

答案2

八年零七个月之后，我们更换了 Stack Exchange 帐户，但 shibd（现在是新版本）仍然有这种行为。

解决这个问题的最好但很笨拙的方法是每天使用 crontab 运行一次

service shibd restart

在过去，这本身就是一个令人头疼的问题，因为大型元数据文件意味着 shibd 需要花费很多时间才能重新加载。当前版本的 shibd 允许“按需”从远程主机加载元数据，这意味着重新加载现在不再那么麻烦。

相关内容