Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gethotbyname error continued



I'm workng on the assumption that gethostbyname() is actually opening up 
the socket and not closing it. 
But, it may also be a related issue, such as the application is opening 
sockets and not closing. Calls like gethostbyname() do open sockets 
implicitly. 

But, I would look at the application. does it explicitly open a new 
connection each time and not close. 

lsof might be able to help diagnose the problem. Gethostbyname() might only 
be the symptom. 

If this is a threaded app, a thread may be opening a socket without closing 
it. Unlike a process, a thread does not automatically clean up after 
itself. 
On 18 Jun 2002 at 16:57, Patrick R. McManus wrote:

> [Jerry Feldman: Tue, Jun 18, 2002 at 04:48:45PM -0400]
> > endhostent() should take care of that. 
> > It's kind of too bad that Purify has not been ported to Linux. Purify would 
> > be able to tell you that very quickly, but ....
> 
> The sockets that take all his fd's are from his network protocol code,
> not the namelookup at all. Literally his call to socket() not an
> implicit one in the name resolution code.
> 
> 1021 was a very obvious number on linux, where the default fds per
> process is 1024. in this case that's 1021 plus stdin, stdout, stderr.
> 
> -P
> 


--
Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org