> But this is a daemon that notices changes in user prefs files in real time
so
> the performance issue is spurious. It's _already_ taking a performances
hit
> _every single time_ for every single user.
No. For several reasons.
1) Usually user rules are disallowed. So all SA has to do is open
On Sun, Mar 20, 2005 at 07:06:10PM -0800, Vicki Brown wrote:
> What's one more on rare occasions, really?
Exactly, "rare occasions". Just send a SIGHUP.
> I'm sorry. I don't buy the arguments. I will remain unconvinced.
Ditto. :)
--
Randomly Generated Tagline:
"It was nice of you to let me re
At 13:55 -0500 03/20/2005, Theo Van Dinter wrote:
>Well, that's not sendmail rereading the config. "newaliases" generates
>a new DBM/hash file from a flat text file. Sendmail then realizes the
>file (that it has open) has changed and reopens the new file for access.
>The DB is a lookup table, not
At 13:55 -0500 03/20/2005, Theo Van Dinter wrote:
>> I simply do not believe there can be a "substantial hit" if spamd re-reads
>> the config file
>
>Besides the fact there are tens of config files that would have to be
>watched (
It's _already_ watching and __reading__ "tens of config files".
m
Vicki Brown wrote:
At 17:40 -0800 03/19/2005, jdow wrote:
There is a substantial hit, Vicki, on the order of a factor of two on
my machines.
We are talking about Only when the Config File has Changed_. OK, so you get a
factor of two, what, once a week?
Sendmail does this (you run newaliases or "ma
On Sun, Mar 20, 2005 at 10:39:26AM -0800, Vicki Brown wrote:
> Sendmail does this (you run newaliases or "make"to trigger it).
Well, that's not sendmail rereading the config. "newaliases" generates
a new DBM/hash file from a flat text file. Sendmail then realizes the
file (that it has open) has