The following reply was made to PR general/885; it has been noted by GNATS.
From: Dean Gaudet <[EMAIL PROTECTED]> To: Illuminatus Primus <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: general/885: After a period of time (not found to coincide with server rehashes or any specific access), the server will read requests, but return no data (and close the connection). It will still respond to a server-status request though. Date: Tue, 18 Nov 1997 18:36:37 -0800 (PST) On Fri, 14 Nov 1997, Illuminatus Primus wrote: > Yes, I realize that ap_slack tries to return the original fd if a new one > cannot be allocated, but unforunately if there are lots of fds open and > fcntl fails to remap the fd on a 2.0.29 kernel, it will return a closed fd > :).. maybe i misworded the sentence about open() returning -1 once in a > while.. I don't see this wrong behaviour at all. You mentioned this output for 2.0.29: On 2.0.29 (ISS patch #4), this is the behavior right before it reaches it's descriptor limit: myfd: 3 slacked up: 253 myfd: 3 slacked up: 254 myfd: 3 slacked up: 255 myfd: 3 slacked up: 3 myfd: 4 slacked up: 4 myfd: 5 slacked up: 5 myfd: 6 slacked up: 6 myfd: 7 slacked up: 7 myfd: 8 slacked up: 8 myfd: 9 slacked up: 9 myfd: 10 slacked up: 10 myfd: 11 slacked up: 11 myfd: 12 slacked up: 12 myfd: 13 slacked up: 13 myfd: 14 slacked up: 14 myfd: -1 slacked up: -1 This is perfectly correct behaviour. file descriptor 3 is closed during all the cases where ap_slack successfully moves it. When it fails, it returns 3 without closing it. Nothing looks wrong. The difference with 2.1.x is that it supports more descriptors per process, but you also have to increase the system-wide number of files. Something like "echo 4096 >/proc/sys/kernel/file-max" will do the trick. Either that or you can "limit descriptors 64" and test with a smaller number per task. Dean
