Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1217 closed Defect (fixed)

wired netstat output

Reported by: toralf Owned by: davea
Priority: Undetermined Milestone: Undetermined
Component: Client - Work Fetch Policy Version: 7.0.36
Keywords: Cc:

Description (last modified by Christian Beer)

Well, I'm really unsure whether this is an BOINC client issue, but I'd like to start here. At my Gentoo Linxu I run a netstat program yesterday b/c the upllaod of an Einstein@Home job was initiated but then seems to hang for a while. I get with netstat as a common user :

$ netstat --tcp --udp --program -n
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:52945         127.0.0.1:31416         TIME_WAIT   -                   
tcp        1      0 92.224.126.35:39614     170.224.194.69:443      CLOSE_WAIT  -                   
tcp        0      0 92.224.126.35:39938     88.198.244.100:563      ESTABLISHED 25439/thunderbird   
tcp        1      0 92.224.126.35:37372     198.20.8.241:443        CLOSE_WAIT  -                   
tcp        1      0 92.224.126.35:47148     198.20.8.246:443        CLOSE_WAIT  -                   
tcp        0      0 92.224.47.110:38287     198.20.8.246:80         ESTABLISHED -                   
tcp        0    539 92.224.47.110:53332     129.89.61.70:80         ESTABLISHED -                   
tcp        1      0 92.224.126.35:39616     170.224.194.69:443      CLOSE_WAIT  -                   
tcp        1      0 92.224.126.35:37370     198.20.8.241:443        CLOSE_WAIT  -                   

and with sudo :

$ sudo netstat --tcp --udp --program
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        1      0 g224126035.adsl.a:39614 vhost0579.dc1.on.:https CLOSE_WAIT  5196/wcg_faah_autod 
tcp        0      0 g224126035.adsl.a:39938 news.eternal-sept:nntps ESTABLISHED 25439/thunderbird   
tcp        1      0 g224126035.adsl.a:37372 grid.worldcommuni:https CLOSE_WAIT  5196/wcg_faah_autod 
tcp        1      0 g224126035.adsl.a:47148 www.worldcommunit:https CLOSE_WAIT  5196/wcg_faah_autod 
tcp        0      0 g224047110.adsl.a:38287 www.worldcommunity:http ESTABLISHED 5196/wcg_faah_autod 
tcp        0    539 g224047110.adsl.a:53332 einstein.phys.uwm.:http ESTABLISHED 5196/wcg_faah_autod 
tcp        1      0 g224126035.adsl.a:39616 vhost0579.dc1.on.:https CLOSE_WAIT  5196/wcg_faah_autod 
tcp        1      0 g224126035.adsl.a:37370 grid.worldcommuni:https CLOSE_WAIT  5196/wcg_faah_autod 

What me really wonders is the the World Community Grid Task FightAids?@Home seems to connected to the Einstein@Home server.

What's the explanation for this console output ?

FWIW I configured my BOINC client to have both 0 for the minimum work buffer and the additional work buffer.

Attachments (1)

konsole_output_boinc.log (25.0 KB) - added by toralf 12 years ago.
full output of the KOnsole

Download all attachments as: .zip

Change History (7)

Changed 12 years ago by toralf

Attachment: konsole_output_boinc.log added

full output of the KOnsole

comment:1 Changed 12 years ago by Christian Beer

Description: modified (diff)

comment:2 Changed 12 years ago by Nicolas

I can reproduce this; it has been happening since forever. I suspect BOINC isn't marking its network sockets as "close on fork", so the science apps inherit them.

comment:3 Changed 12 years ago by davea

Resolution: fixed
Status: newclosed

Fixed (I think).

comment:4 Changed 12 years ago by toralf

Well, I wouldn't have a problem, if something like "BOINC daemon" is sees instead of the science app - but a science app is assigned to the "wrong" w3 address, or ?

comment:5 Changed 12 years ago by davea

The issue was that if an app is started while a scheduler RPC is in progress, it "inherits" the RPC's network connection, and it remains open as long as the app is running. The fix was to set a flag causing the connection to not be inherited.

comment:6 Changed 12 years ago by toralf

Ah - now I understood - from #comment 3 I thought that no fix will be applied to the source code related to this issue.

Note: See TracTickets for help on using tickets.