Actions
Bug #384
closedWhen relayd is killed on the remote side, the local ports remain hanging in CLOSE_WAIT
Status:
Invalid
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
10/23/2012
Due date:
% Done:
0%
Estimated time:
Description
Description: ============ Bug-374 has been fixed; unfortunately, one other scenario that still cause the local port to stay in CLOSE_WAIT. When the relayd dies from the remote node, the local node will have their opened ports hanged in CLOSE_WAIT. Commit used: ============ userspace: e7e6ff7 rculfhash test: fix trivial memleak and return node leak and errors lttng-ust: 1c7b4a9 Fix: memcpy of string is larger than source lttng-tools: dda67f6 Fix: Error handling when sending relayd sockets to consumer babeltrace : 6ca30a4 Cleanup: fix cppcheck warning Scenario: ========= 1) <from node1> lttng-relayd -vvv -C tcp://0.0.0.0:52000 -D tcp://0.0.0.0:54000 -o /temp/ & 2) <from node2> lttng create ses1 -U net://192.168.0.1:52000:54000/./ lttng list lttng enable-event com* -u lttng start; netstat -etan |egrep '52000|5400' Local Address Foreign Address State 192.168.0.3:42282 192.168.0.1:54000 ESTABLISHED 192.168.0.3:54421 192.168.0.1:52000 ESTABLISHED 3) <from node1> netstat -etan |egrep '52000|5400' Local Address Foreign Address State 192.168.0.1:54000 192.168.0.3:42282 ESTABLISHED 192.168.0.1:52000 192.168.0.3:54421 ESTABLISHED 4) <from node1> pkill relayd netstat -etan |egrep '52000|5400' Local Address Foreign Address State 192.168.0.1:54000 192.168.0.3:42282 FIN_WAIT2 192.168.0.1:52000 192.168.0.3:54421 FIN_WAIT2 5) <from node2> netstat -etan |egrep '52000|5400' Local Address Foreign Address State 192.168.0.3:42282 192.168.0.1:54000 CLOSE_WAIT 192.168.0.3:54421 192.168.0.1:52000 CLOSE_WAIT
Updated by Tan le tran almost 12 years ago
The above bug report is invalid. It makes sense to have the ports remain in CLOSE_WAIT as the corresponding session is still active on the local side ! Once, deactivated (ie: lttng stop), the corresponding ports are propperly closed. However, the consumerD becomes <defunct> after "lttng destroy". If possible, can we have the header of this bug modified to reflect consumerD got defunct ? The following are the continuation from the above steps: 6) <from node2> lttng stop netstat -etan |egrep '52000|5400' (no more ports opened...all ports have been closed) ps -ef |grep lttng lttng-consumerd --quiet -u --consumerd ... lttng-sessiond -d 7) <from node2> lttng destroy ps -ef |grep lttng [lttng-consumerd] <defunct> <========= consummerD becomes <defunct> lttng-sessiond -d
Updated by David Goulet almost 12 years ago
- Status changed from New to Invalid
No I can not really change the subject of the ticket.
I'll open a new one with this bug being related! (and I'll answer it)
I will also flag this bug as invalid.
Actions