[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>