[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deliver to scripts...
Tom Samplonius wrote:
> On Tue, 21 Feb 1995, Rich Salz wrote:
>
> > > > > 373: cannot fdopen(8) (retry in 45s, expires in 2h57m24s)
> > > System is running at the default limit of 2048 file descripters per
> > > process, so I don't think this is a problem.
> >
> > If you are running on SunOS it is a problem. Sun4.x libc cannot handle
> > filedescriptors greater then 128. (grep fileno /usr/include/stdio.h).
> > A common occurrence is that open succeeds, returns fd # 135 or so, and
> > then fdopen() fails because libc thinks it's got a negative number.
> > Sun's response to bug reports is "upgrade to Solaris"
>
> Ok, I'm not using Sun. I'm using FreeBSD, and I'm running with the
> default kernel configuration of 2048 file descriptors per process.
And furthermore the "fd" in question is 8, so even Suns would
not become troubled with it..
Btw: Solaris maxima for fd is 1024, but STDIO uses u_char
as storage for fd (if you get a middle finger extender muscle
cramp from this, you perhaps need to consider GNU libc :-/)
With router we saw a very difficult case of stdio-fd leakage,
which was partly caused by my "mistake" of removing
fileno(fp) = -1;
fclose(fp);
from the code (it was actually a lot more convoluted).
The file-descriptor in question was not to be closed, but
stdio-fp was needed to be deallocated..
It sure does give a feel of same kind of situation.
Tom, will it happen:
- with fresh start of the scheduler with empty queue
aside of this one job ?
- or only after several jobs ?
I would like to see your scheduler.conf -file, and
the alias you use to drive the script.
> Tom
/Matti Aarnio <mea@nic.funet.fi>