https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6303
--- Comment #6 from Mark Martinec <mark.marti...@ijs.si> 2010-02-10 07:14:07 UTC --- > > Since you are already running amavisd-new, why do you not let it call > > SpamAssassin directly, and save yourself and your mailer the trouble > > of dealing with two content filters? > > Ops... if you know the best configuration, welcome! Can you get me > one or two example (or link for this example)?? Unless you explicitly disable spam checking in amavisd.conf (by @bypass_spam_checks_maps or its derivatives), amavisd is calling SpamAssassin by default. You may need to adjust score thresholds and what should happen to spam, but that is basically all. Something like: @bypass_spam_checks_maps = (); $sa_tag2_level_deflt = 5.0; # labels passed mail as spam $sa_kill_level_deflt = 8.5; # blocks & quarantines at this level $sa_spam_subject_tag = '***SPAM*** '; $final_spam_destiny = D_DISCARD; $spam_quarantine_to = 'spam-quarantine'; $spam_quarantine_method = 'local:spam-%m.gz'; or to just label spam but deliver anyway: $final_spam_destiny = D_PASS; > > Anyway, back to the reported problem. There are no defunct (zombie) > > processes on your system according to the output of top(1). 86.8%id - idle is good, host is only lightly loaded. > this morning after same problems, I have search parent (PPID) of spamd defunct > process. The parent was /usr/sbin/spamd -d -c -L -r /var/run/spamd.pid . > I stop the deamon and after, the same defunct process after change parent in > the PPID 1 (init). Is correct?? Yes, this is correct behaviour. It is a function of the init process to garbage collect all orphaned process entries and clear them. After a short while the reparented defunct entries should be removed by the init process. So that spamd parent process which you had to kill was the culprit. It failed to collect exit statuses of (i.e. to ripe) its child processes which had already terminated some time ago. Don't know why this would happen. It was stuck for some reason, or lost track of its child processes. Was this process dormant when you killed it, or was it spinning CPU? Was it still able to accept connections and process them? Running it with debugging enabled and examining log from such process when a problem reoccurs might shed some light. > > There are indeed lots of open TCP sessions to localhost port 783 > > in a CLOSE_WAIT state. Unfortunately you have not provided a full > > list of processes as reported by ps(1). According to the port number > > and the CLOSE_WAIT state I can assume each of these correspond to an > > existing spamd child process, where its spamc client has long gone, > > but for some reason spamd failed to close its end of the socket. > > I'm sorry, i have restart server after read this part. one or two day (next > problems) and I test with lsof the process join this close_wait > The only events join this problems is backup but are not sure! The backup is a > tar command and mysql-dump and the cpu go tu 2 or 3. For some reason that parent spamd process which you had to kill got stuck when you are running a backup. Now that you mention a mysql dump, perhaps this causes bayes/awl tables to be locked during a backup, thus blocking spamd operations. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
