mainSpamAssassin Milter Plugin - Support: sr #100680, milter and spamc hang

 
 

sr #100680: milter and spamc hang

Submitter:  None
Submitted:  Mon 01 Apr 2002 06:08:42 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 Dec 2005 09:07:48 AM UTC, comment #9: 

I have also noticed the same behavior. Kernel 2.4.26, Sendmail 8.12.11, Mail::SpamAssasin 3.0.2, spamass-milter 0.3.0.

The worst is that the dead spamass-milter processess keep accumulating file descriptors until the limit is reached and spamass-milter dies completely. Right now, there are 72 spamass-milter processes in my system (due to recent restart, usually there are several hundreds). The oldest one has 220 file descriptors open. It is not very difficult to hit the fd limit (which is rather high in this system, 209708).

Anonymous
Wed 19 Jun 2002 12:23:07 PM UTC, comment #8: 


I too have seen this problem today when trying to install
this software.

However, doing some quick debugging, I have found that when
it happens (and it happens when two or more messages arrive
at about the same time (the 2nd arrives before the 1st is
still being processed at some point)) that not only is
spamass-milt blocked on a read, but so too is the spamc
process.

I'm trying to get this working on a FreeBSD4.5R machine.

# gdb spamc 58757
(gdb) where
#0  0x280df2b8 in read () from /usr/lib/libc.so.4
#1  0x8048aca in full_read (fd=0, buf=0x8052000 "",
min=257024, len=257024)
    at spamc.c:105
#2  0x8048c49 in send_message (in=0, out=3,
username=0x8051000 "root",
    max_size=256000) at spamc.c:169
#3  0x8049517 in process_message (hostname=0x804a040
"127.0.0.1", port=783,
    username=0x8051000 "root", max_size=256000) at
spamc.c:482
#4  0x8049819 in main (argc=1, argv=0xbfbffa58) at
spamc.c:594
#5  0x8048979 in _start ()

Not only that... But when I was doing this debugging, I had
started the milter in the foreground. When I did a ^Z then a
"bg" command to put into the background, it did infact
string into life. When I managed to send several emails at
the same time to cause the block again, was when I did the
above gdb command.

Well... back to the source code...

Invalid User ID <#8270>
Sun 07 Apr 2002 01:23:20 PM UTC, comment #7: 


On the machine I am testing it on, its fairly easy to make
it hang.  Just send a 5 attachments at the maching running
the milter at abount the same time, and you will need to
restart the milter daemon after that :-(

In the version I have if I have it core dump I see

(gdb) where
#0  0x281344b8 in _thread_sys_read ()
from /usr/lib/libc_r.so.4
#1  0x281305e8 in _read () from /usr/lib/libc_r.so.4
#2  0x28130645 in read () from /usr/lib/libc_r.so.4
#3  0x804f76b in SpamAssassin::empty_and_close_pipe
(this=0x8079380) at spamass-milter.cpp:863
#4  0x804f27c in SpamAssassin::input (this=0x8079380) at
spamass-milter.cpp:721
#5  0x804d8c7 in mlfi_eom (ctx=0x8078580) at spamass-
milter.cpp:507
#6  0x28073c47 in mi_clr_macros ()
from /usr/lib/libmilter.so.2
#7  0x280730e8 in mi_engine () from /usr/lib/libmilter.so.2
#8  0x28072d55 in mi_handle_session ()
from /usr/lib/libmilter.so.2
#9  0x280724fe in mi_thread_handle_wrapper ()
from /usr/lib/libmilter.so.2
#10 0x280f6557 in _thread_start () from /usr/lib/libc_r.so.4
#11 0x0 in ?? ()
(gdb)

Like 863 is size=read(pipe_io[1][0],iobuff,1024);



// Read all output from SpamAssassin client
// and close the pipe
//
void
SpamAssassin::empty_and_close_pipe()
{
  long size;
  int  status;
  char iobuff[1024];
  string reason;

  do {

    size=read(pipe_io[1][0],iobuff,1024);

and 721 is   empty_and_close_pipe();


SpamAssassin::input()
{
  // if the child has exited or we experienced an error,
return
  // immediately.
  if (!running || error)
    return;

  // keep reading from input pipe until it is empty
  empty_and_close_pipe();


So it seems to be blocking on waiting for input from the
pipe (presumably) to the spamc process.
I guess the question is, what is the best way to deal with
such issues ?

---Mike

Anonymous
Sun 07 Apr 2002 01:23:11 PM UTC, comment #6: 


On the machine I am testing it on, its fairly easy to make
it hang.  Just send a 5 attachments at the maching running
the milter at abount the same time, and you will need to
restart the milter daemon after that :-(

In the version I have if I have it core dump I see

(gdb) where
#0  0x281344b8 in _thread_sys_read ()
from /usr/lib/libc_r.so.4
#1  0x281305e8 in _read () from /usr/lib/libc_r.so.4
#2  0x28130645 in read () from /usr/lib/libc_r.so.4
#3  0x804f76b in SpamAssassin::empty_and_close_pipe
(this=0x8079380) at spamass-milter.cpp:863
#4  0x804f27c in SpamAssassin::input (this=0x8079380) at
spamass-milter.cpp:721
#5  0x804d8c7 in mlfi_eom (ctx=0x8078580) at spamass-
milter.cpp:507
#6  0x28073c47 in mi_clr_macros ()
from /usr/lib/libmilter.so.2
#7  0x280730e8 in mi_engine () from /usr/lib/libmilter.so.2
#8  0x28072d55 in mi_handle_session ()
from /usr/lib/libmilter.so.2
#9  0x280724fe in mi_thread_handle_wrapper ()
from /usr/lib/libmilter.so.2
#10 0x280f6557 in _thread_start () from /usr/lib/libc_r.so.4
#11 0x0 in ?? ()
(gdb)

Like 863 is size=read(pipe_io[1][0],iobuff,1024);



// Read all output from SpamAssassin client
// and close the pipe
//
void
SpamAssassin::empty_and_close_pipe()
{
  long size;
  int  status;
  char iobuff[1024];
  string reason;

  do {

    size=read(pipe_io[1][0],iobuff,1024);

and 721 is   empty_and_close_pipe();


SpamAssassin::input()
{
  // if the child has exited or we experienced an error,
return
  // immediately.
  if (!running || error)
    return;

  // keep reading from input pipe until it is empty
  empty_and_close_pipe();


So it seems to be blocking on waiting for input from the
pipe (presumably) to the spamc process.
I guess the question is, what is the best way to deal with
such issues ?

---Mike

Anonymous
Sun 07 Apr 2002 07:37:00 AM UTC, comment #5: 


Yes - you are not alone.
I also restart spamass-milter several times a day.
(0.1.1)
The process id doesn't correspond to the also often found
timeouts of spamass_milter.

And my spamd (contacted by spamc) logs nearly every run:
spamd[6492]: bad protocol: header error: (closed before
headers)

Beside of that, I suppose it's runnig very well. Mails
affected by timouts do hang and will be resent by remote MTA
quite often!?

Anders

Invalid User ID <#6519>
Sun 07 Apr 2002 03:16:51 AM UTC, comment #4: 


Yeah, I am seeing the same thing.  Its the milter thats
hanging. If I kill it and restart it all is well. Spamd
seems to be fine.  No idea where or why its blocking like
this :-(

Anonymous
Sun 07 Apr 2002 12:54:08 AM UTC, comment #3: 


Yeah, I am seeing the same thing.  Its the milter thats
hanging. If I kill it and restart it all is well. Spamd
seems to be fine.  No idea where or why its blocking like
this :-(

Anonymous
Fri 05 Apr 2002 04:31:57 PM UTC, comment #2: 


Has anybody else seen this activity or am I an odd case? I
have to reset spamass-milter and spamd every 2 hours or the
number of stuck processes is just way too high.

Also, if anybody could give me any advide on how to try and
debug this it would be greatly appreciated.

Anonymous
Tue 02 Apr 2002 02:39:30 PM UTC, comment #1: 


Upgrading to the current code in CVS did not correct the
problem. I will keep looking for the solution.

Anonymous
Mon 01 Apr 2002 06:08:42 PM UTC, original submission:  


Hello all, first let me start by letting you know that
I really appreciate all the great work you have been
doing with making a milter to do what spamassassin
does. I have it currently running on my development
server filtering mail for well over 10,000 users and
the response has been great. 

The only real problem I have seen so far is that some
of the threads spawned by spamass-milter hang and
never properly close. After about 2 hours of running
this I have several hundred spamass-milter threads
stuck and many times the spamc process is hung with
it. I noticed in another thread that there are
problems with mail messages < 250K but the problem I
am having does not appear to be caused by this. I
would be happy to help debug this and fix the problem
is I could get an idea as to what is causing it and
where to start looking.

I am running

Redhat 7.2 - Linux 2.4.10 kernel
Sendmail 8.11.6
Perl 5.6.0
spamassasin 2.11
spamass-milter 0.1.1

I hope this is enough info. If not please let me know
and I will get it to you.

Andrew Armstrong
Director of Applications Development
andrew at highertech.net

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

No changes have been made to this item

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code