Ладно, это меня пугает - я вижу примерно 1500-2500 таких:
root@wherever:# netstat
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:60930 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60934 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60941 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60947 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60962 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60969 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60998 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60802 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60823 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60876 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60886 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60898 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60897 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60905 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60918 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60921 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60673 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60680 localhost:sunrpc TIME_WAIT
[etc...]
root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942
Это число быстро меняется.
У меня довольно жесткая конфигурация iptables, поэтому я понятия не имею, что может вызвать это. Любые идеи?
Спасибо,
Тамас
Изменить: вывод netstat -anp:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:60968 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60972 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60976 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60981 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60980 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60983 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60999 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60809 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60834 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60872 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60896 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60919 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60710 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60745 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60765 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60772 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60558 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60564 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60600 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60624 127.0.0.1:111 TIME_WAIT -
РЕДАКТИРОВАТЬ: tcp_fin_timeout НЕ контролировать продолжительность TIME_WAIT, она жестко запрограммирована на 60 с
Как упоминалось другими, наличие некоторых связей в TIME_WAIT является нормальной частью TCP-соединения. Вы можете увидеть интервал, изучив /proc/sys/net/ipv4/tcp_fin_timeout:
[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
И измените его, изменив это значение:
[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Или навсегда, добавив его в /etc/sysctl.conf
net.ipv4.tcp_fin_timeout=30
Кроме того, если вы не используете службу RPC или NFS, вы можете просто отключить ее:
/etc/init.d/nfsd stop
И полностью выключить
chkconfig nfsd off
TIME_WAIT - это нормально. Это состояние после закрытия сокета, используемое ядром для отслеживания пакетов, которые могли быть потеряны и поздно явились на сторону. Большое количество подключений TIME_WAIT - это признак получения большого количества недолговечных подключений, не о чем беспокоиться.
Это не важно. Все это означает, что вы открываете и закрываете множество TCP-соединений Sun RCP (1500-2500 из них каждые 2-4 минуты). В TIME_WAIT Состояние - это то, во что входит сокет при закрытии, чтобы предотвратить поступление сообщений для неправильных приложений, как если бы сокет был повторно использован слишком быстро, а также для нескольких других полезных целей. Не беспокойся об этом.
(Если, конечно, вы на самом деле не запускаете ничего, что должно обрабатывать такое количество операций RCP. Тогда беспокойтесь.)
Что-то в вашей системе выполняет много RPC (удаленных вызовов процедур) в вашей системе (обратите внимание, что и источник, и место назначения - localhost). Это часто наблюдается для lockd для монтирования NFS, но вы также можете увидеть это для других вызовов RPC, таких как rpc.statd или rpc.spray.
Вы можете попробовать использовать «lsof -i», чтобы узнать, у кого открыты эти сокеты, и посмотреть, что это делает. Наверное, безвредно.
tcp_fin_timeout НЕ контролирует TIME_WAIT задержка. Вы можете увидеть это, используя ss или netstat с -o, чтобы увидеть таймеры обратного отсчета:
cat /proc/sys/net/ipv4/tcp_fin_timeout
3
# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24
NetidRecv-Q Send-Q Local Address:Port Peer Address:Port
tcp 0 0 192.168.100.1:57516 192.168.0.10:80 timer:(timewait,55sec,0)
tcp 0 0 192.168.100.1:57356 192.168.0.10:80 timer:(timewait,25sec,0)
tcp 0 0 192.168.100.1:57334 192.168.0.10:80 timer:(timewait,22sec,0)
tcp 0 0 192.168.100.1:57282 192.168.0.10:80 timer:(timewait,12sec,0)
tcp 0 0 192.168.100.1:57418 192.168.0.10:80 timer:(timewait,38sec,0)
tcp 0 0 192.168.100.1:57458 192.168.0.10:80 timer:(timewait,46sec,0)
tcp 0 0 192.168.100.1:57252 192.168.0.10:80 timer:(timewait,7.436ms,0)
tcp 0 0 192.168.100.1:57244 192.168.0.10:80 timer:(timewait,6.536ms,0)
даже если для tcp_fin_timeout установлено значение 3, обратный отсчет для TIME_WAIT по-прежнему начинается с 60. Однако, если у вас net.ipv4.tcp_tw_reuse установлено на 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), то ядро может повторно использовать сокеты в TIME_WAIT, если оно определяет, что не будет никаких возможных конфликтов в нумерации сегментов TCP.
У меня тоже была такая же проблема. Я потратил несколько часов, чтобы узнать, что происходит. В моем случае причиной этого было то, что netstat пытается найти имя хоста, соответствующее IP (я предполагаю, что он использует API gethostbyaddr). Я использовал встроенную установку Linux, в которой не было /etc/nsswitch.conf. К моему удивлению, проблема существует только тогда, когда вы действительно выполняете netstat -a (выяснили это, запустив portmap в подробном режиме и в режиме отладки).
Теперь произошло следующее: по умолчанию функции поиска также пытаются связаться с демоном ypbind (Sun Yellow Pages, также известным как NIS), чтобы запросить имя хоста. Чтобы запросить эту службу, необходимо связаться с картой портов portmapper, чтобы получить порт для этой службы. Теперь с Portmapper в моем случае связались через TCP. Затем portmapper сообщает функции libc, что такой службы не существует, и TCP-соединение закрывается. Как мы знаем, закрытые TCP-соединения переходят на некоторое время в состояние TIME_WAIT. Таким образом, netstat улавливает это соединение при листинге, и эта новая строка с новым IP выдает новый запрос, который генерирует новое соединение в состоянии TIME_WAIT и так далее ...
Чтобы решить эту проблему, создайте /etc/nsswitch.conf, который не использует службы rpc NIS, то есть со следующим содержимым:
passwd: files
group: files
hosts: files dns
networks: files dns
services: files
protocols: files
netmasks: files