Previous Entry Поделиться
Кто устанавливает соединения??
dil wrote in ru_linux
Как определить, что это за процессы, если netstat в колонке "PID/Program name" показывает просто минусы ?
# netstat -ntp | grep de.st.ip.adr:9128  | grep -v TIME_WAIT
tcp        0    758 lo.ca.l.ip:44316           de.st.ip.adr:9128         ESTABLISHED -                   
tcp        0      1 lo.ca.l.ip:44317           de.st.ip.adr:9128         SYN_SENT    -                   
tcp        0      0 lo.ca.l.ip:44315           de.st.ip.adr:9128         ESTABLISHED -  


А соединений с тем сервером в состоянии TIME_WAIT вообще сотни, и у всех тоже минусы.
У соединений с другими серверами процессы в основном показываются, но почему-то тоже кроме TIME_WAIT.
Отчего такое может быть? И как определить, что это за процессы?
Метки:

  • 1
(Анонимно)
TIME_WAIT is the state that typically ties up the port for several minutes after the process has completed.

Процесс кончился, а сокет какое-то время еще живет. В колонке "имя процесса" показывать просто нечего. Это обычное дело для TIME_WAIT. Для других состояний тоже может быть, что процесс помре, не закрыв сокет, тогда сокет какое-то время будет хранить свое последнее состояние; а могут быть и другие причины, например, процесс бежит под рутом (тогда только рут может посмотреть его имя/пид) или там вообще никакого процесса изначально нет и соединение управляется непосредственно ядром.

Ну естественно, я под рутом смотрю. Соединения однозначно устанавливались не ядром, а неким приложением, которое в своём логе постоянно ругается на неустанавливаемость соединений с этим сервером, потому я и полез смотреть, что не так.

lsof -i | grep ":9128" -- что говорит?

Виноват. Теряю былую лёгкость.
lsof -i :9128 (или какой там у тебя порт)




Да это примерно то же самое. lsof -i :9128 и lsof -i TCP:9128 всё равно ничего не показывают

То есть, я правильно понимаю, что netstat это показывает, а lsof нет?

Ага. netstat показывает сокеты, даже если они уже не привязаны к процессам, а lsof - только привязанные.

Эээээ. Если учесть, что netstat читает /proc/net, а lsof -- /dev/kmem, есть ощущение, что поломалось что-то либо в procfs, либо в том, что пишет в /proc/net.

Похоже, в первом комментарии правильная идея - процесс(ы) отваливаются, а сокеты остаются.

Если бы сокеты оставались, lsof бы их увидел, как минимум -- он же действует квадратно-гнездовым методом: лезет в kernel memory и тупо сканит живую таблицу дескрипторов.
А вот почему процесс сдох, дескриптор вычищен (иначе lsof бы его увидел), а procfs об этом ни сном ни духом -- это интересно.

меня смущает, что никто не посоветовал очевидного: нетстат от рута пробовали? Или не в том дело?
also, рекомендую пытаться переходить на ss.

В первом же комментарии спросили. Естественно, я от рута всё смотрел.

О, пропустил...
А что за приложение, если не секрет?

Написанное местными разработчиками, для соединения с сервером использует curl, а в лог постоянно ругается про Curl Error 7 : 'Couldn't connect to server', а иногда Curl Error 28 : 'Timeout was reached', Curl Error 56 : 'Failure when receiving data from the peer', Curl Error 52 : 'Server returned nothing (no headers, no data)'.

  • 1
?

Log in

No account? Create an account