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 over 11 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 over 11 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