httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: fcntl hanging without anyone holding the lock?
Date Wed, 21 Apr 1999 05:15:40 GMT
The fcntl() stuff is shared by the CLONE_FS option to clone() -- are you
sure the linuxthread manager thread isn't still hanging around with the
shared struct?

Your best bet right now is to hack up the test/test-mutex (or whatever
it's called) and reproduce the problem... make a small test case and mail
it to linux-kernel.  This sounds like a kernel bug.

(Try alan's 2.0.37pre10 too.) 


On Wed, 21 Apr 1999, Manoj Kasichainula wrote:

> On Linux 2.0, glibc 2.0, I run the server in poll-accept mode,
> and I take the following steps:
> 1. Start the server, with 3 ThreadsPerChild, MaxSpareServers = 2
> 2. Hit it with 10 concurrent connections from apachebench, for long
>    enough for perform_idle_server_maintanence to run a few times and
>    start and stop a process or two.
> 3. Stop apcahebench
> 4. SIGTERM the server
> At this point, we still have a few processes hanging around. Some of
> the threads are waiting on other threads, which wait on other threads,
> etc.
> Finally, we hit some threads whih are waiting on fcntl. But checking
> the stack traces, and verifying with lsof, there are no httpd
> processes holding the fcntl lock!
> So, there are two problems. First of all, If a child gets a
> SIGWINCH, and is in the process of dying, it cannot be SIGTERMed, it
> won't deal with the signal because the sigwait threads is busy
> gracefully shutting down the process. There are a few ways to solve
> this problem, all essentially splitting the handling of the graceful
> shutdown message and the immediate shutdown message.
> Second, and the very annoying one, is that children seem to be
> waiting on an unlocked fcntl lock. This only happens when the new
> intraprocess locking code is enabled (NEED_INTRAPROCESS_SERIALIZED_ACCEPT).
> But, even if there is a bug in this code (which I can't find), our
> processes shouldn't be blocked in fcntl if no one is holding the fcntl
> lock, right?
> Manoj

View raw message