Re: [Crm114-general] crm/procmail problems?

[Bill Y. <ws...@me...>]

   From: "Robert L. Harris" <Rob...@rd...>

     In the last 4 days I seem to have started bouncing mail and I've
   tracked it down to procmail and crm114.  The OS is Debian Linux,
   Unstable.  My config has been static for a few months now as has
   the kernel.  Basically what happens is that procmail seems to be
   hanging up trying to lock a file so that it can run a recipie:

It's your .css file- it's overflowed.  You've got the answer below...

   :0fw: /tmp/.msgid.lock
   | /usr/bin/crm -u /home/nomad/crm114 /usr/share/crm114/mailfilter.crm


   /home/nomad/crm114 has this:
   {0}:/home/nomad>ls -la crm114/
   total 27872
   drwxr-xr-x    2 nomad users     4096 Jul 27 10:34 .
   drwxr-xr-x  105 nomad users     8192 Jul 27 10:34 ..
   -rwxr-xr-x    1 nomad users        0 May  2 08:36 allmail.txt
   -rwxr-xr-x    1 nomad users     4688 Jun 14 22:04 blacklist.mfp
   -rwxr-xr-x    1 nomad users     5540 Jul 26 13:12 mailfilter.cf
   -rwxr-xr-x    1 nomad users        0 Jul 27 10:37 nonspam
   -rwxr-xr-x    1 nomad users 12582924 Jul 13 13:30 nonspam.css
   -rwxr-xr-x    1 nomad users  1600323 Jul 13 13:30 nonspamtext.txt
   -rwxr-xr-x    1 nomad users       49 Feb 25 12:34 priolist.mfp
   -rwxr-xr-x    1 nomad users   230134 Apr 30 19:02
   rejected_by_blacklist.txt
   -rwxr-xr-x    1 nomad users        0 May  2 08:36 rejected_by_css.txt
   -rwxr-xr-x    1 nomad users      148 Feb 25 12:05 rewrites.mfp
   -rwxr-xr-x    1 nomad users        0 Jul 25 16:42 spam
   -rwxr-xr-x    1 nomad users 12582924 Jul 26 14:35 spam.css
   -rwxr-xr-x    1 nomad users     1402 May 22 17:25 spamm
   -rwxr-xr-x    1 nomad users  1438480 Jul 26 14:35 spamtext.txt
   -rwxr-xr-x    1 nomad users      972 Jul 13 12:12 whitelist.mfp


   in my procmail log file I can see many request to lock the file:

   procmail: [13508] Tue Jul 27 09:16:40 2004
   procmail: Locking "/tmp/.msgid.lock"
   procmail: [13393] Tue Jul 27 09:16:41 2004
   procmail: Locking "/tmp/.msgid.lock"
   procmail: [13388] Tue Jul 27 09:16:41 2004
   procmail: Locking "/tmp/.msgid.lock"
   procmail: [13383] Tue Jul 27 09:16:42 2004
   procmail: Locking "/tmp/.msgid.lock"
   procmail: [13508] Tue Jul 27 09:16:48 2004
   procmail: Locking "/tmp/.msgid.lock"
   procmail: [13393] Tue Jul 27 09:16:49 2004
   procmail: Locking "/tmp/.msgid.lock"


   I am wondering if something in my CRM114 has changed which makes it run
   considerably longer.  For instance, I'm trying to train my spam filter
   with ham and running this command:

   This take about 15 mins to run.  I just ran across 'cssutil' and found
   this:

   {0}:/home/nomad>cssutil -b crm114/spam.css=20

    Sparse spectra file crm114/spam.css statistics:=20

    Total available buckets          :      1048577=20
    Total buckets in use             :      1048576 =20
    Total in-use zero-count buckets  :          119 =20
    Total buckets with value >=3D max  :            0 =20
    Total hashed datums in file      :      3859653
    Average datums per bucket        :         3.68
    Maximum length of overflow chain :      1048576 =20
    Average length of overflow chain :        -0.50=20
    Average packing density          :         1.00

There it is, right there.  1048577 buckets available, 1048576 in use.

That would cause a lot of problems.

However, if you're running the standard distribution mailfilter.crm,
and not modified mailfilter.cf to turn off microgrooming, this should
not have happened!

First off, a fix - we'll just make your .css file larger.

      mv spam.css oldspam.css
      cssutil -b -r -S 2000000 spam.css
      cssmerge spam.css oldspam.css

and do the same for nonspam.css as well:

      mv spam.css oldspam.css
      cssutil -b -r -S 2000000 spam.css
      cssmerge spam.css oldspam.css

That should clear up your runtime problems.

Now, I have no clue as to why you're getting this far without 
microgrooming purging out the low-valued slots.  

What version of crm114 and of mailfilter are you running.

(note: your nonspam.css is not _full_, but perilously close
to it; running the above will give you plenty of space while we
figure out what happened.)

   -Bill Yerazunis