This problem occurs all the time. I have the following parameters:
kern.maxfiles: 2024
kern.maxfilesperproc: 1821
I did monitor via 'pstat' and the number of open files does correspond to
the maxfilesperproc or EMFILE limit. Newsx quits before kern.maxfiles is
reached.
The FreeBSD port of newsx seems to keep the file descriptors open until the
newsx process quits.
Here is a truss and is looks pretty suspicious when doing the rename(.tmp to
spoolfile). You'll
notice that file descriptors 11, 12, 13 never get closed from the following
marked (++++) lines:
open("/usr/local/news/db/history.hash",0x2,01001770414) = 10 (0xa)
open("/usr/local/news/spool/incoming/.tmp.uunet.387",0x601,0666) = 11 (0xb)
close(11) = 0 (0x0)
open("/dev/urandom",0x0,00) = 11 (0xb)
close(11) = 0 (0x0)
++++open("/usr/local/news/spool/incoming/uunetC4fyxN",0xa02,0600) = 11 (0xb)
open("/usr/local/news/spool/incoming/.tmp.uunet.387",0x601,0666) = 12 (0xc)
close(12) = 0 (0x0)
++++open("/usr/local/news/spool/incoming/uunetFHciyG",0xa02,0600) = 12 (0xc)
open("/usr/local/news/spool/incoming/.tmp.uunet.387",0x601,0666) = 13 (0xd)
close(13) = 0 (0x0)
++++open("/usr/local/news/spool/incoming/uunetPPpqnC",0xa02,0600) = 13 (0xd)
open("/usr/local/news/spool/incoming/.tmp.uunet.387",0x601,0666) = 14 (0xe)
close(6) = 0 (0x0)
close(7) = 0 (0x0)
close(14) = 0 (0x0)
open("/usr/local/news/spool/incoming/uunetI2WR5N",0xa02,0600) = 6 (0x6)
close(4) = 0 (0x0)
close(5) = 0 (0x0)
close(9) = 0 (0x0)
close(10) = 0 (0x0)
close(8) = 0 (0x0)
-----Original Message-----
From: Egil Kvaleberg [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 10:10 AM
To: [EMAIL PROTECTED]
Subject: Re: Too many open files: newsx 1.4pl8
On Fri, 2003-01-10 at 17:11, Triebwasser, Mark wrote:
> Has anyone had issues where newsx gets a "Too many open files" error? I'm
> running newsx on a i386 FreeBSD machine.
>
> >inserting newsx path
> >newsx: can't open incoming spool
> "/usr/local/news/spool/incoming/.tmp.gig2.33553": Too many open files
> >transfer interrupted
> >latest article was 5080555
> >no spool to flush
> >state: pull: cleanup
> >no news is good news!
> >state: aborting server
> >->QUIT
> ><- 205 GoodBye
> >unlocked: /usr/local/news/run/L.33553
> >unlocked: /usr/local/news/run/LOCK.newsx.gig2
> >unlocked: /usr/local/news/run/LOCK.gig2
>
> Should I be changing the shell's limit or should I be doing a kernel
> rebuild?
Good question.
Does this happen every time, or only in heavy load situations?
Although I do not know FreeBSD very well, basically there is usually two
errors for too many open files. EMFILE is open count per process, and
ENFILE is system wide.
I think Posix uses "Too many open files in system" for ENFILE, which
would indicate that you have an EMFILE situation.
I don't *think* that newsx itself should have very many files open at
any one time. It *should* close its files after use - and I've never
heard of such problems.
So it is a bit of a puzzle.
I think the best procedure is to run
newsx under 'strace' to see what really happens. Just do:
$ strace 2>out newsx ...
You may then grep for 'open' and 'close', or you can email me the 'out'
file and I can have a look for anything suspicious.
What is your per-process limit set to, anyway?
Egil
--
Email: [EMAIL PROTECTED]
Voice/videophone: +47 22523641 Voice: +47 92022780 Fax: +47 22525899
Mail: Egil Kvaleberg, Husebybakken 14A, 0379 Oslo, Norway
Home: http://www.kvaleberg.com/
-----------------------------------------------------------------------
This message has been sent to you because you are subcribed to the mailing
list [EMAIL PROTECTED] To remove yourself from this lists, send an email
to
[EMAIL PROTECTED] containing "unsubscribe newsx <your_email_address>"
in the message body.
-----------------------------------------------------------------------
This message has been sent to you because you are subcribed to the mailing
list [EMAIL PROTECTED] To remove yourself from this lists, send an email to
[EMAIL PROTECTED] containing "unsubscribe newsx <your_email_address>"
in the message body.
