Messages in this thread | | | Date | Fri, 7 May 1999 09:53:08 -0700 (PDT) | From | Simon Kirby <> | Subject | named getting stuck in tcp_close (2.2.5-ac1, 2.2.6-ac1-ank1) |
| |
I managed to trace the "named getting stuck in tcp_close" problem a bit further, as it just happened again.
The WCHAN shows the process blocking at tcp_close+505(decimal):
0xc0167048 <tcp_close+428>: cli 0xc0167049 <tcp_close+429>: movl (%edx),%eax 0xc016704b <tcp_close+431>: testl %eax,%eax 0xc016704d <tcp_close+433>: jne 0xc0167052 <tcp_close+438> 0xc016704f <tcp_close+435>: leal 0xfffffffc(%edx),%eax 0xc0167052 <tcp_close+438>: movl %eax,0x18(%esp,1) 0xc0167056 <tcp_close+442>: leal 0x14(%esp,1),%edi 0xc016705a <tcp_close+446>: movl %edi,(%edx) 0xc016705c <tcp_close+448>: pushl %ecx 0xc016705d <tcp_close+449>: popf 0xc016705e <tcp_close+450>: leal 0x30(%esi),%eax 0xc0167061 <tcp_close+453>: decl 0x30(%esi) 0xc0167064 <tcp_close+456>: sete %al 0xc0167067 <tcp_close+459>: testb %al,%al 0xc0167069 <tcp_close+461>: je 0xc0167074 <tcp_close+472> 0xc016706b <tcp_close+463>: pushl %esi 0xc016706c <tcp_close+464>: call 0xc01577fc <__release_sock> 0xc0167071 <tcp_close+469>: addl $0x4,%esp 0xc0167074 <tcp_close+472>: movl $0x1,(%ebx) 0xc016707a <tcp_close+478>: movb 0x28(%esi),%al 0xc016707d <tcp_close+481>: movzbl %al,%ecx 0xc0167080 <tcp_close+484>: movl $0x1,%eax 0xc0167085 <tcp_close+489>: shll %cl,%eax 0xc0167087 <tcp_close+491>: testl $0xa10,%eax 0xc016708c <tcp_close+496>: je 0xc01670a1 <tcp_close+517> 0xc016708e <tcp_close+498>: movl %ebp,%eax 0xc0167090 <tcp_close+500>: call 0xc010fcb8 <schedule_timeout> 0xc0167095 <tcp_close+505>: movl %eax,%ebp 0xc0167097 <tcp_close+507>: cmpl $0x0,0x8(%ebx) 0xc016709b <tcp_close+511>: jne 0xc01670a1 <tcp_close+517> 0xc016709d <tcp_close+513>: testl %ebp,%ebp 0xc016709f <tcp_close+515>: jne 0xc0167074 <tcp_close+472> 0xc01670a1 <tcp_close+517>: movl $0x0,(%ebx) 0xc01670a7 <tcp_close+523>: leal 0x14(%esp,1),%ebx 0xc01670ab <tcp_close+527>: pushf 0xc01670ac <tcp_close+528>: popl %ebp
...which appears to be at the only schedule_timeout call in tcp_close():
if (timeout) { struct task_struct *tsk = current; struct wait_queue wait = { tsk, NULL };
add_wait_queue(sk->sleep, &wait); release_sock(sk);
while (1) { tsk->state = TASK_INTERRUPTIBLE; if (!closing(sk)) break; timeout = schedule_timeout(timeout); if (signal_pending(tsk) || !timeout) break; }
tsk->state = TASK_RUNNING; remove_wait_queue(sk->sleep, &wait);
lock_sock(sk); }
This seems to be causing the blocking. "netstat -a -n -o" output when the process was blocking:
Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address State Timer tcp 0 0 204.174.223.1:22 204.174.223.18:1020 ESTABLISHED off (0.00/0) tcp 0 0 204.174.223.1:22 204.174.223.18:1021 ESTABLISHED off (0.00/0) tcp 28 0 204.174.223.1:53 204.174.223.2:4743 ESTABLISHED off (0.00/0) tcp 33 0 204.174.223.1:53 204.174.223.2:4685 ESTABLISHED off (0.00/0) tcp 32 0 204.174.223.1:53 199.45.67.160:34067 ESTABLISHED off (0.00/0) tcp 32 0 204.174.223.1:53 204.174.223.2:4597 CLOSE_WAIT off (0.00/0) tcp 30 0 204.174.223.1:53 204.174.223.2:4540 CLOSE_WAIT off (0.00/0) tcp 0 1 204.174.223.1:53 206.191.253.3:1842 LAST_ACK on (34.19/8) tcp 0 0 204.174.223.1:2791 10.10.10.240:424 ESTABLISHED off (0.00/0) tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 209.153.213.3:53 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 204.174.223.1:53 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 0.0.0.0:671 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN off (0.00/0) tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN off (0.00/0) (*snip non-tcp stuff*) udp 65440 0 204.174.223.1:53 0.0.0.0:* off (0.00/0) 0 (*snip more*)
I did a "ps auxwl | grep named ; netstat -a -n -o | grep 206.191.253.3:1842" continuously at the shell until the timeout number reached 0, and the connection disappeared and the named process continued (showed WCHAN "do_select") as normal.
So, I guess the question here is should close() be blocking on this socket? Is this a bug in the kernel or in named?
Simon-
| Simon Kirby | Systems Administration | | mailto:sim@netnation.com | NetNation Communications | | http://www.netnation.com/ | Tech: (604) 684-6892 |
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |