linux 2001022711 One new socket to POP provider is opened each time i check mail. None seems to ever close/terminate. Instead they hang on in CLOSE_WAIT state. Quitting mozilla doesn't help, they are left hanging till the OS eventually removes them.
Turned out i had had an old mozilla-bin lurking, holding on to sockets. Sockets DO vanish when mozilla is quit. Rest of the bug remains: I can't see that any of the sockets opened during a session ever time out or otherwise vanish, they only accumulate.
What are your netwerk preferences?
Not sure i understand the question. I use TCP/IP via modem/PPP, linux RH6.2. If you mean mailnews account settings/server preferences, i have nothing checked there. (No automated "get mail" on startup, for instance, no biff intervals.) Server i get mail from is a POP3 server, at default port 110. Outgoing server differs from the one i use to get mail from. This would hardly affect sockets. I see the same problem when it comes to nntp servers btw, hut i think there's a bug on that already. Again: i'm not quite sure what you're asking for? I use a firewall, but the problem is the same when firewall is disabled.
I meant to ask you about keep-alive prefrences, but that is not relevant here. cc'ing darin.
neeti: there is another bug reported about CLOSE_WAIT state sockets hanging around on Linux. reporter: is your system a box stock RH 6.2 ?
No.. not quite stock 6.2: 6.2 with all relevant upgrades (including kernel) + Gnome 1.2.4 and gtk+-1.2.8-1, libnet-1.0.1b-1 Various other installations but none running that should affect networking. Not running any mail-related services. No unusual activities observed.
just wondering b/c on my stock RH 7.0 box i'm not seeing sockets with CLOSE_WAIT hanging around.
seems bug 70605 is a dup.
It's not server-dependant: My ISP's use two different (InterMail and Cubic Circle). Sockets to both servers increment and hang forever in CLOSE_WAIT when i check mail with Mozilla. I rebooted and started afresh, ensuring no firewall was ever started. I dialed up provided BEFORE starting mozilla, so it should see the right IP right away. No cure - the problem persists. Worth noting: Checking mail with NC 4.76 does NOT show this bug - those sockets CLOSE and vanish the moment mail is checked.
This bug now got fixed with the patch attached in bug 71391. I just made a CVS build patching first. Resolving as WFM. Less spam. (It's really a dup of 67957)
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
VERIFIED, per R.K.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.