|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : Bulgakov Sergei 2:5020/400 17 Nov 2000 15:13:58
To : All
Subject : Rsh problems
--------------------------------------------------------------------------------
День добрый!
Ситуация следующая - есть две машины А и В (Slackware 7.0 и 7.1 обе с
ядрами 2.2.17).
А слабенькая, В помощьней. Hа А смонтирован диск В на rw, и люди
работая на А (с диском В) через rsh запускают компилюцию на В и смотрят
результаты на А. Зачем так сделано не спрашивайте - HЕ ЗHАЮ!
Теперь проблема : при запуске через rsh ЛЮБОЙ команды, например:
A> rsh B ls /
команда отрабатывает замечательно, но если на B сразу после завершения
команды
посмотреть состояние tcp сокетов с помощью netstat, то будет примерно
следующая картина:
B>netspat -p
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 B.DOMAIN_B:1020 A.DOMAIN_A:1022
TIME_WAIT -
tcp 0 0 B.DOMAIN_B:auth A.DOMAIN_A:1031
TIME_WAIT -
tcp 0 0 B.DOMAIN_B:shell A.DOMAIN_A:1023
TIME_WAIT -
tcp 0 136 B.DOMAIN_B:1025 C.DOMAIN_C:6000
ESTABLISHED 135/color_xterm
tcp 1 0 B.DOMAIN_B:shell C.DOMAIN_C:961
CLOSE_WAIT 135/color_xterm
tcp 0 0 B.DOMAIN_B:7100 C.DOMAIN_C:4839
ESTABLISHED 126/xfs
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node PID/Program
name Path
unix 1 [ ] STREAM CONNECTED 69
70/sshd @00000002
unix 1 [ ] STREAM CONNECTED 51
65/klogd @00000001
unix 1 [ ] STREAM CONNECTED 192
125/chronyd @00000005
unix 1 [ ] STREAM CONNECTED 110
77/rpc.nfsd @00000004
unix 1 [ ] STREAM CONNECTED 73
74/rpc.mountd @00000003
unix 1 [ ] STREAM CONNECTED 193
62/syslogd /dev/log
unix 1 [ ] STREAM CONNECTED 152
62/syslogd /dev/log
unix 1 [ ] STREAM CONNECTED 151
62/syslogd /dev/log
unix 1 [ ] STREAM CONNECTED 70
62/syslogd /dev/log
unix 1 [ ] STREAM CONNECTED 52
62/syslogd /dev/log
Hа самом деле это можно прочитать напрямую из ядра через /proc/net/tcp
B>cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when
retrnsmt uid timeout inode
0: 69FFFFFF:03FC 69FFFFFE:03FE 06 00000000:00000000 03:000002EE
00000000 0 0 0
1: 69FFFFFF:0071 69FFFFFE:0407 06 00000000:00000000 03:000002EE
00000000 0 0 0
2: 69FFFFFF:0202 69FFFFFE:03FF 06 00000000:00000000 03:000002EE
00000000 0 0 0
3: 69FFFFFF:0406 69FFFFFD:1770 01 00000000:00000000 00:00000000
00000000 1030 0 471
4: 69FFFFFF:0202 69FFFFFD:03C0 08 00000000:00000001 00:00000000
00000000 0 0 444
5: 69FFFFFF:0401 69FFFFFD:1770 01 00000000:00000000 00:00000000
00000000 1030 0 255
6: 69FFFFFF:0202 69FFFFFD:03C1 08 00000000:00000001 00:00000000
00000000 0 0 228
7: 69FFFFFF:1BBC 69FFFFFD:12E7 01 00000000:00000000 00:00000000
00000000 0 0 227
8: 00000000:1BBC 00000000:0000 0A 00000000:00000000 00:00000000
00000000 0 0 217
9: 00000000:008B 00000000:0000 0A 00000000:00000000 00:00000000
00000000 0 0 169
10: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000
00000000 0 0 160
Т.е. три соединения (в состоянии TIME_WAIT) продолжают существовать уже
после закрытия соединения по
rsh, причем закреплены они за ядром !!! Через примерно минуту эти
соединения исчезнут !!!
Hо если в течении этой минуты выполнить примерно 60-70 обращений через
rsh к B, то очередной клиент дает диагностику:
poll: protocol failure in circuit setup
и выподает, а на стороне сервера появляется немерянное колличество
соединений в состоянии TIME_WAIT и inetd впадает в прострацию по порту
rsh, т.е. он продолжает жить, но больше клиентов по rsh он не пускает,
пока не скажешь ему kill -HUP
Резюме: толи я чего-то не допонимаю, толи системе не хватает каких-то
настроек, толи это КОHКРЕТHАЯ дырка в ядре.
Огромное спасибо всем кто дочитал до конца и я буду чудовищно благодарен
за любой комментарий.
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
