httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hess <>
Subject Re: [PATCH] Alerting when fnctl is going bad
Date Thu, 26 Sep 2002 19:10:00 GMT
On Wed, 25 Sep 2002, Sander van Zoest wrote:
> On Wed, 25 Sep 2002, Justin Erenkrantz wrote:
> > On Thu, Sep 26, 2002 at 02:11:59AM +0200, Dirk-Willem van Gulik wrote:
> > > ->	Makes the wait loop no longer endless - but causes it
> > > 	to bail out (and emit some warnings ahead of time) after
> > > 	a couple of thousand consequituve EINTRs.
> > Placing a 'magic number' on how many EINTRs is 'failure' doesn't
> > seem right.  -- justin
> Although, things like these have been done many times in the past.
> Especially in BSD.  As long as the number is high enough to where there
> doesn't seem to be an obvious reason to go above that, then I do not see
> why not.

Is there any other way to detect that the fcntl() is bad, other than "we 
got more than X EINTR"?  For instance, in this case I'm guessing it's 
related to interrupts due to the lockfile being on a network filesystem of 
some sort, and it looks like you could have a server run fine for a couple 
days, then drop itself for no obvious reason.

Every time I've ever seen code which does something different after
getting "too many" EINTR responses, and later rolled that code into a
production environment, it's turned out to be wrong.  EINTR never seems to
happen in development environments :-).  If you're getting "too many"
EINTR results, in my experience it means that the code isn't handling
errors correctly somewhere else, and it will bite you in other ways, so
nowadays I always go looking for the _real_ problem.

[Unless, of course, the OS itself has a bug.  But that should definitely
involve conditional code to fix.]


View raw message