SA Bugzilla – Bug 6618
spamd gives no error when rules directories are missing, poor error on empty rules dir
Last modified: 2011-06-16 14:49:57 UTC
This problem was just reported on IRC by jocom, and google searching indicates others have hit it. jocom's running archlinux, others on freebsd. On my (Ubuntu) system, running trunk, removed /usr/share/spamassassin/ and /var/lib/spamassassin/, then created /var/lib/spamassassin/3.004000 (empty), then: # /etc/init.d/spamassassin start Starting SpamAssassin Mail Filter Daemon: child process [10691] exited or timed out without signaling production of a PID file: exit 255 at /usr/sbin/spamd line 2643. This error should instead state that the rules are missing and you need to run sa-update, much like these do: # spamassassin -t < /dev/null config: no rules were found! Do you need to run 'sa-update'? at /usr/bin/spamassassin line 403. # spamassassin --lint config: no rules were found! Do you need to run 'sa-update'? If all rules directories are completely missing, the behavior is even worse, no error at all.
With no rules directories at all, starts up with no complaints and keeps running. Should probably die with an error. # spamassassin --lint Jun 15 11:57:58.453 [10715] warn: config: could not find sys rules directory # /etc/init.d/spamassassin start Starting SpamAssassin Mail Filter Daemon: spamd. # ps auxww | grep -i spamd root 10719 5.6 2.8 26124 21428 ? Ss 11:58 0:00 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -d --pidfile=/var/run/spamd.pid
"I finally got it working. The actual error was that I had not installed gnupg2" - jocom So it sounds like sa-update depends on gpg and also doesn't give a useful error without it. He previously mentioned he was following this tutorial: https://wiki.archlinux.org/index.php/Postfix_Tutorial
(In reply to comment #2) > "I finally got it working. The actual error was that I had not installed > gnupg2" - jocom > > So it sounds like sa-update depends on gpg and also doesn't give a useful error > without it. > > He previously mentioned he was following this tutorial: > https://wiki.archlinux.org/index.php/Postfix_Tutorial OK, I've got a test system with spamd showing that it has the same error as spamassassin: spamd Jun 15 16:51:09.003 [7354] error: config: no rules were found! Do you need to run 'sa-update'? config: no rules were found! Do you need to run 'sa-update'? Now trying to recreate the gpg scenario...
(In reply to comment #3) > OK, I've got a test system with spamd showing that it has the same error as > spamassassin: Figured out the difference, try it with -d and you'll get the same lack of useful error. # spamd -d # As used by /etc/init.d scripts child process [8930] exited or timed out without signaling production of a PID file: exit 255 at /usr/sbin/spamd line 2588. # spamd Jun 15 17:15:48.485 [8932] error: config: no rules were found! Do you need to run 'sa-update'?
(In reply to comment #4) > (In reply to comment #3) > > OK, I've got a test system with spamd showing that it has the same error as > > spamassassin: > > Figured out the difference, try it with -d and you'll get the same lack of > useful error. > > # spamd -d # As used by /etc/init.d scripts > child process [8930] exited or timed out without signaling production of a PID > file: exit 255 at /usr/sbin/spamd line 2588. > > # spamd > Jun 15 17:15:48.485 [8932] error: config: no rules were found! Do you need to > run 'sa-update'? I concur. Found that but also researching the GPG issue.
> > Figured out the difference, try it with -d and you'll get the same lack of > > useful error. I'm 99.9% sure this is an Invalid bug report. With -d, the information is logged to syslog which would be appropriate for a daemon. Without -d, is there a specific case that you can point out that should be resolved? However, it seems we could use some additions to Dependency.pm to test for required/optional binaries such as gpg. I'll attach a patch with my first pass at doing so. The test_version subroutine might be reinventing the wheel or doing things very much the hard way so if anyone has any input, I'm all ears. Darxus and others, can you remove gpg from your path (or change your path) and test this patch? Would be good if you can play with the required/recommended versions and test as well with gpg in the path. All you have to do for a test is perl Makefile.PL CONTACT_ADDRESS=Darxus@ChaosReigns.com The goal of this patch is to prompt that the optional gpg is not installed and this is required for sa-update to function. It also gives a framework built off the existing MODULES and OPTIONAL_MODULES functionality for binaries. Regards, KAM
Created attachment 4918 [details] Patch to allow DependencyInfo.pm to test for required and optional binaries with a check for gpg
(In reply to comment #6) > The goal of this patch is to prompt that the optional gpg is not installed and > this is required for sa-update to function. Since when is it required? sa-update should be usable with the --nogpg option, even if it is not recommended.
(In reply to comment #8) > (In reply to comment #6) > > The goal of this patch is to prompt that the optional gpg is not installed and > > this is required for sa-update to function. > > Since when is it required? sa-update should be usable with the --nogpg option, > even if it is not recommended. The code in the patch for checking the gpg binary is clear that it's an optional binary but the verbiage of sa-update says: error: gpg required but not found! But I agree it's technically not required and this is all just communication problems with the end-user. I'll update the error message as well to be a bit more clear and use the same verbiage in the optional check. Attaching a new version of my patch in a second. Regards, KAM
Created attachment 4919 [details] Improved Patch to allow DependencyInfo.pm to test for required and optional binaries with a check for gpg & clean up gpg error message in sa-update
Created attachment 4920 [details] Same as v2 with disabled module tests re-enabled. I had disabled them to speed up debugging.
Closing as resolved -> Invalid. Error messages with -d are sent to syslog. Will create a new bug for the DependencyInfo.pm/sa-update error messages rather than continue with a hijacked bug.