http://bugzilla.spamassassin.org/show_bug.cgi?id=4153
------- Additional Comments From [EMAIL PROTECTED] 2005-05-18 14:51 -------
Transfering some the discussion from the dev list:
>From [EMAIL PROTECTED]:
ust an FYI, I'm considering a veto on the spamc config file patch.
Admittedly, I got very busy and wasn't able to review the patch as
closely as I would have liked. This is a feature that will NOT be used
by 99% of the spamc users and it was my understanding for those 99% it
was going to be a NOP with nothing done at all with the config file (not
even a half dozen checks to see if the file exists).
Now, it looks like the functionality has switched to always on and
always checking for the existence of the config file. I understand the
usefulness of the feature but it should not affect everyone else using
spamc. At the very least, we shouldn't be issuing an error when the
config file can't be found, talk about a support nightmare, everyone and
their dog will be filing bugs, asking on the mailing lists and in IRC
about that file.
Like I said, I'm about -.9 on this patch at the moment, but am willing
to be convinced that it's the right thing to do going forward.
Michael
>From John Madden:
I suppose since I want the patch in, I should follow up on this.
The logging can be turned off or require debugging or something - that's
not a problem. I can't see an easy way around searching for the log file
though, unless it's a compile time variable. Currently it's a bit of
both : if SA is built through the usual perl Makefile.PL && make
scenario, then the config file is #define'd and doesn't need to be
searched for. If it doesn't exist, operation continues as normal. If
spamc is built on its own, without --sysconfdir passed to configure,
then @SYSCONFDIR@ contains ${prefix}, which is why the extra parsing and
searching is needed.
The checks can be reduced, so that if a _single_ file doesn't exist,
then continue processing and don't look anywhere else. It can even be
removed completely, and if @SYSCONFDIR@ contains ${prefix}, then don't
search for a config at all, and skip it completely.
I think its uses for the 1% outweigh the negative for the 99%. If it's
over-searching or over-logging, then that code can all be removed, and
leave a simple single search for one config file in its place. I know
for our setup, a global config file would be very useful. As it is, I'm
running a patched version of spamc to point to a host other than
localhost, so we don't have to force around 400 users to change their
.procmailrc files. This feature, even if not the exact patch submitted,
has definite uses, and I'd definitely like to see it in a future
release.
>From Michael Parker:
Here is a quick benchmark to illustrate my point, spamc.old was the revision
immediately before the conf patch, spamc.new is the conf patch revision:
Benchmark: timing 10000 iterations of spamc.new, spamc.old...
spamc.new: 97 wallclock secs ( 0.61 usr 2.70 sys + 14.37 cusr 26.04 csys =
43.72 CPU) @ 3021.15/s (n=10000)
spamc.old: 39 wallclock secs ( 0.48 usr 2.36 sys + 13.73 cusr 23.52 csys =
40.09 CPU) @ 3521.13/s (n=10000)
Michael
>From Justin Mason:
ouch. that *is* slow.
OK, we have the following options imo:
- leave it that it will look for a default config file in one location
only, with one stat() operation. This is my preferred option.
- same as above, with a possible $SPAMC_CONFIG env variable allowed
to set the location. still only one stat() op, so it's fast,
but it does allow people with odd installs to specify the file
location, if that's a desirable feature. in my opinion, this isn't
really required, since they can just use -F.
- remove the code. I'm not too happy with this, since it's a long-desired
feature and fixes another reported bug.
- only check for a config file if the -F command line switch is present;
in other words, no default config file. that doesn't fix the reported
bug, either.
ps: yes, that "config file cannot be found" warning has to go; there's a
bug open about that already.
pps: would probably have been better to discuss this on the bugzilla entry
btw.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
