[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mailbox processes growing



On Thu, Dec 07, 2000 at 08:22:34PM +0300, Eugene Crosser wrote:
> It seems that unreasonable growth of mailbox processes is not connected
> with "-S" option: they grow without it as well.  That is, before
> mimeheaders reorganization.  Now I put in production recent CVS version,
> will see if things change...

    I saw such hyper-growth two days ago myself too.
    It did lead to out-of-memory condition, and all merriment
    what *that* one causes..

Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
Out of Memory: Killed process 26690 (mailbox).
__alloc_pages: 0-order allocation failed.
VM: killing process mailbox

    (yeah, linux kernel really repeated itself like that..)

    I have that mailbox running with -S,  and I *think* the case
    is related to having malformed incoming headers, but damned
    if I could determine what -- naturally it cleared itself auto-
    magically without enabling me to repeat the test.

    I had a hunch that *lack of*   Content-Transfer-Encoding:
    header with otherwise normal MIME message is related to this,
    but the blasted thing didn't repeat :-/   --> my hunch could
    be wrong.

    I think the message in question was some sort of spam coming
    into my system.  I think it had these headers ( + some Receiveds):

From:   <lauren554@achill.net>
To:     matti.aarnio@sonera.com
Subject: HI ...              
Reply-To: lauren32@jahoopa.com
Mime-Version: 1.0
Content-Type: text/plain, charset="iso-8859-1"
Date:   Thu, 7 Dec 2000 01:09:13

    Notably it is missing  Message-ID and Content-Transfer-Encoding.



    In couple hours time I will be leaving for flights to San Diego
    IETF (www.ietf.org), and while I have quite excellent network
    connectivity from there, I am also quite busy.

    ... but in case I have free cycles, and nothing better to do,
    I might look into  getpwnam()  return code checks, at least...

> Eugene

-- 
/Matti Aarnio	<mea@nic.funet.fi>