Many TIME_WAIT connection

[emmanux]

This is pretty much easy to reproduce. Put a zabbix agent inside a VM, cut off the real machine's network, not the VM's network. Reconnect on the physical machine, with other ip, route, whatever. It should happen if there were "ESTABLISHED" connections going on during the outage.

SSH handles these situations pretty well, it has a timeout. Not the case of the zabbix agent.

Please fix it as soon as possible.

In the meanwhile, I'm going to manage this via script executed from a cronjob.

[AnthonyKolka]

I ran onto this same condition on a proxy this morning. The same error messages:

failed to accept an incoming connection: connection rejected, getpeername() failed: [107] Transport endpoint is not connected

The key thing in my situation was the call to getpeername(). This proxy is for a large amount of hosts that have RFC 1918 addresses, and when each one connects the zabbix proxy does a PTR lookup on the address. Each of these lookups were coming back very slowly from our DNS server (over 3 seconds) causing the issue. Switching the primary resolver in resolv.conf to a resolver that rejects RFC 1918 PTR lookups immediately resolved the issue.

During the investigation I noticed that all of the trappers were showing a status of "processing data" and none where ever idle. After making the change I finally saw idle trappers again.

I hope this helps someone, and Zabbix, we should be able top turn off PTR lookups for incoming connections in the zabbix proxy configuration file.

[DARKINATY]

Which maybe prooves that some people are not able to write "decent" Applications ( reusing/opening Ports, binding ports, closeing ports ... )

Had the same problem but it was an OS issue. Fixed it by modifing the sysctl.conf file as follows: