> Hello Craig, > > I recently ran into this problem myself. The solution, > after being a dolt and not running a backup first, was > the following sequence followed by line definitions: > > /etc/init.d/mailserver stop > sa-learn --backup > /etc/mail/spamassassin/database.bak > sa-learn --dump magic > sa-learn --no-sync --ham --progress --mbox > /export/home/brian/Ham sa-learn --sync > sa-learn --no-sync --spam --progress --mbox > /export/home/brian/Spam sa-learn --sync > sa-learn --dump magic > spamassassin -D --lint > /etc/init.d/mailserver start > > 1) Shutdown Sendmail/ClamAV/MIMEDefang/Spamassassin. > 2) Backup the database. > 3) View current statistics which will also display the > current bayes database version. > 4) Do a ham learn. > 5) This one was key! Even after everything was parsed > and the command line came back, the database was still > not in a happy place. Doing the --sync brings it to that > happy place. 6) Do a spam learn. > 7) See #5. > 8) View current statistics and note nham and nspam > increases. 9) Run through the rules to make sure > everything is still cool and no errors occur. > 10) Start Sendmail/ClamAV/MIMEDefang/Spamassassin. > > Notes: > > - Doing a --sync on the sa-learn learning process didn't > work. I'm not sure why the system doesn't learn the file > and then just resync the database when it's done. Maybe > Theo has an idea. - Shutting down the MTA isn't ideal but > it prevents lock file conflicts which don't seem to work > too well under Solaris 8. Mail queues in the ether for > about 30 minutes while all of this is going on. I've > even thought about automating the process which would > help keep the Ham and Spam files at a reasonable size and > shorten that to about 5 minutes. > > -BE >
Why do you put that --no-sync argument after each learning command in the first place? I have used it when learning several messages one at a time, and then later --sync But in your script, I see no reason for 1st learning with --no-sync and then --sync after it.
