Error message named[7052]: can't fdopen tmpfile (sec/db.135.1 5.p2 aGXn)

[England, Robert (Robert)]

I have 35 DNS servers; all are the same version of BIND. The only 2 giving
me issues are in our DMZ, Up until the other night, every thing was fine,
even with them. I have checked the file permissions as suggested. Everything
looks good. I compared these servers with the other to verify this. The
archives are a great source of Info. Just remember these archives do get a
little dated, and may not always reflect a solution for issues in the newer
versions of BIND. Did I say that I didn't buy the list or the one answer????
Don't read between the lines!!

Thanks for your Help!

> -----Original Message-----
> From: Jim Reid [mailto:jim at rfc1035.com]
> Sent: Wednesday, January 23, 2002 6:32 PM
> To: England, Robert (Robert)
> Cc: bind-users at isc.org
> Subject: Re: Error message named[7052]: can't fdopen tmpfile
> (sec/db.135.15.p2 aGXn)
> 
> >>>>> "Robert" == England, Robert (Robert)
> <england at northamerica.exchange.agere.com> writes:
> 
>     Robert> Can someone give me some insight into the following error
>     Robert> message "named[7052]: can't fdopen tmpfile
>     Robert> (sec/db.135.15.p2aGXn)" ?  I looked at the BIND archives,
>     Robert> for this issue and it states a file permissions issue. I
>     Robert> do not buy that.
> 
> Well if you choose to believe that, you're implying that the list
> archives and therefore by implication the list readership is wrong. So
> then what's the point of asking on this list if in your eyes it's a
> source of false information?
> 
> Check your local documentation for fdopen() and see if any of the
> other failure conditions might hold. It's possible but unlikely that
> something has run out of file descriptors or something like that. Even
> so, the most probably explanation for fdopen() to fail on a zone
> transfer is a file system access permissions problem, just like the
> list archives said.