Thanks pterobyte. I checked and it was already _amavisd:_amavisd for /var/amavis/.spamassassin.
The files in it are as follows:
-rw------- 1 _amavisd _amavisd 21004288 Aug 12 2012 auto-whitelist
-rw------- 1 _amavisd _amavisd 95688 Aug 12 2012 bayes_journal
-rw------- 1 _amavisd _amavisd 5185536 Aug 12 2012 bayes_seen
-rw------- 1 _amavisd _amavisd 5025792 Aug 12 2012 bayes_toks
This means they haven't been touched since the install. And some of the messages include R/W on the files:
5/19/13 3:05:38.700 PM org.amavis.amavisd: bayes: cannot open bayes databases /var/amavis/.spamassassin/bayes_* R/W: tie failed: No such file or directory
I'm quite sure this has NOT been going on since 8/12/2012. I do look at the system log from time to time.
Any other thoughts?
There seems to be a perl crash each time this happens. Here is the top of the crash log:
Process: perl5.12 
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: spawn 
Date/Time: 2013-05-19 15:17:50.831 -0400
OS Version: Mac OS X Server 10.7.5 (11G63)
Report Version: 9
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000105038fbc
VM Regions Near 0x105038fbc:
__DATA 0000000105010000-0000000105017000 [ 28K] rw-/rwx SM=PRV /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/libperl.dylib
--> __LINKEDIT 0000000105017000-0000000105039000 [ 136K] r--/rwx SM=COW /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/libperl.dylib
MALLOC metadata 0000000105039000-000000010503a000 [ 4K] r--/rwx SM=ZER
The parent process is "spawn" a process run by postfix "master" process to spawn up processes with priveledges. Seems like it may be here to look next.
$daemon_user = '_amavisd'; # (no default; customary: vscan or amavis), -u
$daemon_group = '_amavisd'; # (no default; customary: vscan or amavis), -g
Thanks for the ideas.
Also getting this in system log right before the postfix/spawn: perl crash:
5/22/13 2:56:34.033 PM ReportCrash: DebugSymbols was unable to start a spotlight query: spotlight is not responding or disabled.
Going to rebuild spotlight on system disk to see if this goes away.Well it has stopped but that may not be why.
I finally tracked down the Perl crashes for greylisting and this solved those issues:
Since those perl crashes have stopped, now the amavis/spamassassin issues have gone too. Perhaps the crashing "spawn" of the greylisting was affecting stuff further down the line and causing the amavis issues to show up. But they are gone now too.
Hope this helps someone. Thanks to pterobyte for being there!
You are right about getting it sorted. But i need to know why in the end; i just can't help myself.
The policy server is the greylisting perl script that was crashing, /usr/libexec/postfix/greylist.pl. The rest of postfix is compiled binaries and a few sh scripts.The link to the other thread:
tells you to delete the berkeley db files that either get damaged or too large, then the greylist.pl won't crash and will create new db files, which worked. I am pretty sure from looking at the master.cf file and main.cf files that the greylist.pl policy server is run before the email is even accepted for delivery, after which the amavis/spamassasin gets run on the content. So a crashing greylist.pl policy server could screw up the process that was handling the connection such that amavis/spamassasin would get open errors on their databases.
The bigger issue here is that apple is sending out a greylist.pl that is not robust enough to tell you what is going on when it can't read the berkeley db files it creates and manages, and then also that the db files get corrupted. I previously used a greylisting solution that i added onto my Leopard servers that used mysql databases and i never saw a problem with those getting corrupted.
pterobyte, hope you are having pleasant spring weather in Swizerland! We are getting our spring showers and flowers.
You could always install Postgrey. It is easier to maintain and rock solid.
Here is a how-to:
P.S. Spring didn't find its way to Switzerland this year. But we are still hopeful. :-)