Re: 2.0.30 crash in lock_remove_locks (>256fd's)

Michael L. Galbraith (
Sat, 17 May 1997 08:19:48 +0200 (MET DST)

On Fri, 16 May 1997, Carlo Wood wrote:

> | Bottom line is that this breaks one *hell* of a lot of stuff.. better really
> | need it if you start because you'll end up recompiling nearly every library/
> | binary in your system to get things straight again. BTDT: reverted to 256 :)
> Indeed I needed to recompile every program that uses select() of FD_ZERO,
> and also strace, to use it. But I did not (yet) recompile libc, is that needed
> too ?

I don't know about *must*, but I sure think you should and a lot more because..

mikeg:# glimpse -y -H /usr/local/src '{ FD_ZERO, FD_SET, FD_ISSET, FD_CLR, NR_OPEN, OPEN_MAX }'|wc -l

Glimpse isn't set up to read tar archives at the moment.. if it were, it'd be a
*lot* worse. /usr/local/src is mostly system stuff.

This query went a long way toward curing my curiosity-putzing :)).

> Note that everything now seems to work, it compiles and I can use 4096 fd's
> per process. But select() still 'hangs' and gets very slow, it doesn't look
> good. For instance, I can NOT connect more then about 670 clients to an
> irc server, the rest drops off after hanging in select a while and then
> error-ing on write() with ETIMEDOUT (after select returned because of another
> reason).
> Carlo

Yes, that's what happened here as far as performance/hanging goes. I tried
setting fd's to 4096 w. libc and the X tree recompiled. System didn't work
for spit afterward. (mountd, procmail, ... , named, gated, ... broken)

BTW: if it sounded like I was slamming the patch, not the case.. I like it
a lot. Applying and maintaining increased # of fd's globally is where I had
problems. Looked like a permanent discover-damage/recompile project to me. (Oskar Pearson) is using it on 7 machines with no problems.
Perhaps he can give you a tip as to how to do this in a non-global manner?