I think we need to try and rule out the spamc/spamd combination with milter.
Can anyone think of a good way to try and trigger two spamc calls at the same time to see if that hangs? I don't think it would be to hard to change the $_ to $msg (or some other variable). I do like the $_ used as it seems like a waste to setup another variable for this. Craig might have a different idea on this though. I haven't heard of any $_ problems but who knows :-) If Craig doesn't have any other ideas, I might try changing the $_ to $msg tonight (time permitting). The threading suport in FreeBSD is VERY different from Linux and that is why I started looking at spamass-milter. ---- Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools (780) 429-8308 [EMAIL PROTECTED] -----Original Message----- From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 3:42 PM To: Kirk Davis Cc: Craig Hughes; [EMAIL PROTECTED] Subject: RE: [SAtalk] Partial analysis of FreeBSD/spamass-milter hang ... The one issue that I know exists in FreeBSD is we've had known problems with threads for the longest time ... is it possible that the problem is in milter itself? Not even necessarily spamass-milter, but milter itself? If we are going to concentrate on the perl side of things, in spamd, what would it take to do: $msg = <STDIN>; INstead of: $_ = <STDIN>; A friend of mine mentioned that there have been issues with using $_ in a forked environment ... ? Something about $_ being global, even if declared local? On Wed, 13 Feb 2002, Kirk Davis wrote: > OK. I have done some ktrace dumps on both the milter process and > the milter with childs (milter->spamc). I'm not sure it is a problem with > spamc or spamd. It seems to be the spamass-milter process. The last thing > I see in common in both of these traces is a the spamass-milter trying to > read from the spamc process. > > I am a good at perl but my C++ sucks. If anyone wants to take a > look at these logs then just email me and I'll send you a copy. I'm going to > forward a copy on to Craig and Marc though. I would be great if we can > squash this one bug. > > ---- Kirk > > Kirk Davis > Senior Network Analyst, ITS > Edmonton Public Schools > (780) 429-8308 > [EMAIL PROTECTED] > > > > -----Original Message----- > From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 13, 2002 10:35 AM > To: Craig Hughes > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [SAtalk] Partial analysis of FreeBSD/spamass-milter hang > ... > > > > Okay, have added what I think are the appropriate FreeBSD mailing lists > for this, since I know I can't answer this :( > > > On 13 Feb 2002, Craig Hughes wrote: > > > Ok, any perl/BSD gurus out there? It spawns a new process but then > > hangs trying to read STDIN from the new subprocess? This is either a > > BSD bug or a perl-on-BSD bug, I think. There might be a way to work > > around it though -- the trick would be to find some other forking tcp > > daemon which does work... > > > > C > > > > On Tue, 2002-02-12 at 19:07, Marc G. Fournier wrote: > > > > > > Okay, here you go ... a hang: > > > > > > =============== > > > logmsg: connection from earth.hub.org [ 64.49.215.11 ] at port 4329 > > > logmsg: before spawn > > > > > > logmsg: after spawn > > > > > > logmsg: connection from earth.hub.org [ 64.49.215.11 ] at port 4331 > > > logmsg: before spawn > > > > > > logmsg: after spawn > > > > > > ================= > > > > > > And pertinent area of code: > > > > > > ================= > > > logmsg "before spawn\n"; > > > spawn sub { > > > $|=1; # always immediately flush output > > > > > > logmsg "after spawn\n"; > > > # First request line off stream > > > local $_ = <STDIN>; > > > > > > logmsg "got STDIN\n"; > > > if (!defined $_) { > > > protocol_error ("(closed before headers)"); > > > return 1; > > > } > > > ===================== > > > > > > On 12 Feb 2002, Craig Hughes wrote: > > > > > > > Ok, interesting. n(spamc)+1 spamd's means that the fork already > > > > happened for both spamd's. Could you stick a trace on the spamd > process > > > > though instead of spamass-milter? I'd like to try and figure out > where > > > > it's getting to before it gets stuck. Possible alternative to ktrace > > > > (and possibly more useful) would be to add logging messages to the > spamd > > > > code just after where it forks to see how far it's getting before it > > > > jams up. > > > > > > > > C > > > > > > > > On Tue, 2002-02-12 at 18:08, Marc G. Fournier wrote: > > > > > > > > > > Don't know how helpful this will be, but, just started it up and > watched > > > > > it hang ... > > > > > > > > > > According to /var/log/maillog, as previously noted, the hang is > based on a > > > > > simultaneous arrival of two messages: > > > > > > > > > > Feb 12 22:01:53 earth sendmail[91753]: g1D21pkw091747: > to=<[EMAIL PROTECTED]>, delay=00:00:02, xdelay=00:00:00, mailer=cyrus, > pri=30679, relay=localhost, dsn=2.0.0, stat=Sent > > > > > Feb 12 22:01:53 earth sendmail[91692]: g1D21bkw091692: Milter add: > header: X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.01 > > > > > Feb 12 22:01:54 earth sendmail[91758]: g1D21bkw091692: > to=<[EMAIL PROTECTED]>, delay=00:00:17, xdelay=00:00:01, mailer=cyrus, > pri=138802, relay=localhost, dsn=2.0.0, stat=Sent > > > > > Feb 12 22:02:01 earth sendmail[91780]: g1D21wkw091780: > from=<[EMAIL PROTECTED]>, size=13424, class=0, nrcpts=1, > msgid=<[EMAIL PROTECTED]>, proto=ESMTP, > daemon=MTA, relay=mail2.stockwatch.com [207.102.62.11] > > > > > Feb 12 22:02:01 earth sendmail[91819]: g1D221kw091819: from=<>, > size=6395, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, > proto=ESMTP, daemon=MTA, relay=zanaco.com [64.49.215.210] > > > > > > > > > > processes of hte spam programs shows: > > > > > > > > > > earth# ps ax | grep spam > > > > > 90082 ?? IsJ 0:00.10 /usr/bin/perl /usr/local/bin/spamd -d -A > 64.49.215.11 -u nobody -s local1 > > > > > 91784 ?? IJ 0:00.00 /usr/bin/perl /usr/local/bin/spamd -d -A > 64.49.215.11 -u nobody -s local1 > > > > > 91821 ?? IJ 0:00.00 /usr/bin/perl /usr/local/bin/spamd -d -A > 64.49.215.11 -u nobody -s local1 > > > > > 90171 p1 IJ 0:00.20 /usr/local/bin/spamass-milter > /var/run/spamass.sock > > > > > 91783 p1 IJ 0:00.01 /usr/local/bin/spamc > > > > > 91820 p1 IJ 0:00.01 /usr/local/bin/spamc > > > > > > > > > > And a tail end of a ktrace shows (before I killed off all the > processes), > > > > > using kdump -l: > > > > > > > > > > (c) Copyright 2002 Canjex Publishing Ltd. > http://www.stockwatch.com\r > > > > > \r > > > > > \r > > > > > \r > > > > > \r > > > > > \r > > > > > \r > > > > > > **************************************************************************\r > > > > > A fee was NOT paid to Stockwatch for the distribution of > this bulletin.\r > > > > > THIS IS NOT A RECOMMENDATION TO BUY OR SELL ANY > SECURITY!\r > > > > > To remove yourself from this mailing list, access this > URL:\r > > > > > http://www.stockwatch.com/sw/unsubscribe.dbm\r > > > > > For more information about this service please contact > the\r > > > > > advertising department at Stockwatch 800.268.NEWS or > 604.687.1500\r > > > > > > *************************************************************************a\r > > > > > \r > > > > > " > > > > > 90171 spamass-milter RET write 13228/0x33ac > > > > > > > > > > And, after killing them off: > > > > > > > > > > > **************************************************************************\r > > > > > A fee was NOT paid to Stockwatch for the distribution of > this bulletin.\r > > > > > THIS IS NOT A RECOMMENDATION TO BUY OR SELL ANY > SECURITY!\r > > > > > To remove yourself from this mailing list, access this > URL:\r > > > > > http://www.stockwatch.com/sw/unsubscribe.dbm\r > > > > > For more information about this service please contact > the\r > > > > > advertising department at Stockwatch 800.268.NEWS or > 604.687.1500\r > > > > > > *************************************************************************a\r > > > > > \r > > > > > " > > > > > 90171 spamass-milter RET write 13228/0x33ac > > > > > 90171 spamass-milter CALL poll(0x80a2800,0x1,0) > > > > > 90171 spamass-milter RET poll 1 > > > > > 90171 spamass-milter CALL write(0x6,0xbfacbe24,0x5) > > > > > 90171 spamass-milter GIO fd 6 wrote 5 bytes > > > > > "\0\0\0\^Ac" > > > > > 90171 spamass-milter RET write 5 > > > > > 90171 spamass-milter CALL poll(0x80a2800,0x1,0) > > > > > 90171 spamass-milter RET poll 1 > > > > > 90171 spamass-milter CALL read(0x6,0xbfacbde4,0x5) > > > > > 90171 spamass-milter GIO fd 6 read 5 bytes > > > > > "\0\0\0\^AE" > > > > > 90171 spamass-milter RET read 5 > > > > > 90171 spamass-milter CALL fstat(0x9,0xbfacbd0c) > > > > > 90171 spamass-milter RET fstat 0 > > > > > 90171 spamass-milter CALL close(0x9) > > > > > 90171 spamass-milter RET close 0 > > > > > 90171 spamass-milter CALL read(0xa,0xbfacb994,0x400) > > > > > 90171 spamass-milter PSIG SIGTERM caught handler=0x2812c4b4 > mask=0x0 code=0x0 > > > > > 90171 spamass-milter RET read RESTART > > > > > 90171 spamass-milter CALL sigreturn(0xbfacb6cc) > > > > > 90171 spamass-milter RET sigreturn JUSTRETURN > > > > > 90171 spamass-milter CALL read(0xa,0xbfacb994,0x400) > > > > > 90171 spamass-milter PSIG SIGKILL SIG_DFL > > > > > earth# > > > > > > > > > > does this help any? > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Spamassassin-talk mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/spamassassin-talk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Spamassassin-talk mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/spamassassin-talk > >
Kirk Davis.vcf
Description: Binary data
