Соединения Apache2/Shibboleth TCP застряли в CLOSE_WAIT

Question

Соединения 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 означает, что, когда удаленный сервер отключается, локальное приложение не может закрыть соединение, как должно. Я подозреваю, что Шибд как-то ответственен.

Излишне говорить, что если накопилось достаточно соединений CLOSE_WAIT, у меня проблема.

Попытка избавиться от соединений CLOSE_WAIT, просто используя

/etc/init.d/networking restart

не работает. Фактически, сеть, кажется, отказывается закрываться и перезапускаться, и я получаю сообщение SIOCADDRT: файл существует (т. Е. Сеть пытается начать работу, не остановившись сначала). Та же проблема с ifup -a

Поэтому у меня два вопроса - один может быть легким, а другой сложнее.

Какой хороший способ заставить сеть перезагрузиться и заставить все соединения, застрявшие в CLOSE_WAIT, очистить?
Любые идеи о том, как исправить Shibboleth и заставить Shibd модуль вести себя?

2

apache-2.2 linux-networking shibboleth

Источник

RJT 14 ноя '11 в 01:09

1 ответ

Другие вопросы по тегам apache-2.2 linux-networking shibboleth

David Schwartz 14 ноя '11 в 01:16 2011-11-14 01:16 · Answer 1 · 2011-11-14 01:16

К сожалению, ответ на 1 состоит в том, чтобы перезапустить процесс, который все еще имеет ссылки на соединения. Ничто другое не заставит его close их.

1

Источник

David Schwartz 14 ноя '11 в 01:16

fred2 22 июн '20 в 01:49 2020-06-22 01:49 · Answer 2 · 2020-06-22 01:49

Спустя восемь лет, семь месяцев и другая учетная запись Stack Exchange, а shibd (теперь в новой версии) все еще имеет такое поведение.

Наилучший, но совершенно неуклюжий способ решения проблемы - использовать crontab примерно раз в день для запуска.

service shibd restart

В прошлом это было само по себе головной болью, поскольку большие файлы метаданных означали, что перезагрузка shibd занимала много минут. Текущая версия shibd позволяет "по мере необходимости" загружать метаданные с удаленного хоста, что означает, что перезагрузка теперь менее проблематична.