On Sun, Apr 22, 2001 at 11:26:59PM -0400, Lee Chin wrote: > This is more of a Linux socket API question... I have a server thread that > accepts (accept sys call) socket connections and then services a client > request and closes the socket connection using: > > shutdown(fd, SHUT_RDWR); > close(fd); Quaint... I use just close(fd) for that. Do you mean the fd STAYS behind if you do that ? (As shown by the /proc/XXX/fd/ pseudo-directory ?) If it does, it may be indicative of some bug in the system. Which kernel version you are running ? What architecture ? > My problem is this... after a while I see that the file descriptor returned > by the accept system call slowly starts increasing. It starts increasing in > the integer file descriptor number returned by the system call (the FD that > we use to do the read and write system calls). It won't increase beyond the limit of: getrlimit(RLIMIT_NOFILE, &rlimits) (See "man getrlimit") > I have two problems: > 1) I'm using the file descriptor as an index into a fixed size array Make sure its size is at least your number-of-files limit. > 2) I'm scared of eventually running out of file descriptors. In general you will sooner or latter encounter a situation where you will run out of file descriptors -- it all depends just on the lifetimes of the connections. Prepare for it. If the average lifetime exceeds the average in between birth- events (accept()s), your population (number of fds) will increase. > Further more, when I do a "file /proc/PID/fd/XXX" I get a "/proc/PID/fd/XXX: > broken symbolic link to socket:[BLAH]" > > Why is this file descriptor still lingering around and how do I get rid of > it when I do a close on the socket? Is it really lingering ? Like I said in the beginning, it may be a kernel bug, in which case we need to know which kernel version you are using. > Thanks > Lee /Matti Aarnio - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
