Description of problem: xinetd stops accepting connections. When the rate limit kicks in, it stops accepting connections, but then when it tries to restart the service it has an error, leaving the service unavailable. Version-Release number of selected component (if applicable): xinetd-2.3.11-2.AS2.1 How reproducible: Happens frequently on a live server with high load. I don't know how to reproduce on a test server. Steps to Reproduce: 1. 2. 3. Actual results: Feb 7 08:52:05 venus xinetd[4926]: Deactivating service smtp due to excessive incoming connections. Restarting in 30 seconds. Feb 7 08:52:35 venus xinetd[4926]: bind failed (Address already in use (errno = 98)). service = smtp Feb 7 08:52:35 venus xinetd[4926]: Error activating service smtp Expected results: Feb 6 05:00:53 venus xinetd[4926]: Deactivating service smtp due to excessive incoming connections. Restarting in 30 seconds. Feb 6 05:01:23 venus xinetd[4926]: Activating service smtp Additional info: This is happening on average 1 per month, but sometimes it will happen twice on the same day.
I have upgraded to the latest upstream version of xinetd, xinetd-2.3.14. This version still seems to have the problem. I have also enabled periodic consistency checking with SIGIOT. After a while, this happens: service smtp: actual running servers = 43, known running servers = 14 Consistency check detected 1 errors So there is obviously something going wrong here.
I already have similar report for RHEL4, see bug #232595. All I need is deterministic reproducer. I was running series of scripts generating some random traffic over the night, but the service was always correctly restarted after a timeout. Can you see some pattern in logs when the service gets deactivated and following restart fails? Full log of xinetd and content of config files (incl. /etc/xinet.d/*) could help, but I am afraid I can't do too much without the reproducer.
Since there has been no activity here for a significant amount of time and this issue most certainly won't be fixed in RHEL2, I'm closing the bug. If the issue persists, feel free to open a new bug for current release of RHEL, but before you do, please gather data that are missing both here and in bug 232595.