Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I run an Apache2 server which uses the Shibboleth daemon (shibd) as federated authentication module. Certain server connections using Shibboleth seem to stick permanently in CLOSE_WAIT state.

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 

From what I can find out, CLOSE_WAIT means that when the remote server disconnects, the local application is failing to close the connection, as it should. I suspect shibd is responsible somehow.

Needless to say, if enough CLOSE_WAIT connections accumulate, I have a problem.

Trying to get rid of the CLOSE_WAIT connections by simply using

/etc/init.d/networking restart

does not work. In fact networking seems to refuse to close down and restart, and I get a SIOCADDRT: File exists error (ie networking is trying to start without having stopped first). Same problem with ifup -a

So I have two questions - one may be easy, and one harder.

  1. What's a good way to force networking to restart, and force whatever connections are stuck in CLOSE_WAIT to clear?
  2. Any ideas about how to fix shibboleth and force shibd module to behave?
share|improve this question
add comment

1 Answer 1

The answer to 1, unfortunately, is to restart the process that still has references to the connections. Nothing else will force it to close them.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.