On 08/03/06 09:17 PM, Dan Mahoney, System Admin wrote:
On Tue, 7 Mar 2006, Theo Van Dinter wrote:
On Tue, Mar 07, 2006 at 08:14:38PM -0500, Dan Mahoney, System Admin
wrote:
[Odd SQL Error]
The only VERY ODD error I am seeing now (and only for ONE user) is this:
Mar 7 20:19:12 quark spamd[83564]: config: failed to parse line,
skipping: rewrite_subject_0
Mar 7 20:19:12 quark spamd[83564]: config: failed to parse line,
skipping: report_header_1
Mar 7 20:19:12 quark spamd[83564]: config: failed to parse line,
skipping: use_terse_report_1
Mar 7 20:19:12 quark spamd[83564]: config: failed to parse line,
skipping: defang_mime_0
Mar 7 20:19:12 quark spamd[83564]: config: failed to parse line,
skipping: auto_learn_0
Why are these odd? None of these are valid config lines for 3.1.
Because my configs are in a SQL database, and for that user, the config
lines look totally normal. For this user only, the SQL interpreter is
adding an underscore where there shouldn't be one. The user doesn't
even have a homedir on the system where spamd runs -- and spamd runs as
user "spamd" who has no prefs of its own.
Just because the configs are in a SQL database, doesn't mean that
they'll work even though they are invalid. ;)
Underscore or not, they're not valid.
[pyzor, razor, dcc]
I could see trouble with any ONE of these things -- but all three?
Something feels odd.
Do you have a firewall blocking those services from working?
No firewall at all, and those processes hit (as in, generate scores)
most of the time. I'm under the impression if they were going to be
killed by a firewall config, it would be a very all or nothing type thing.
It's a realtek NIC, but that shouldn't matter at all since ALL this box
does is mysql and spam processes (less than a meg). Duplex is 100/full
(auto) on a known good (but unmanaged) switch.
Well, if the timeouts (and they are just timeouts) are congestion
related, it would make sense that all three would timeout.
And there was the mention I saw earlier of still-escaping alarms.
However, I haven't had a true lockup since making all these changes.
Usually those happen late at night when I say "they musta fixed it,
things haven't locked up in a while..." :)
Mine only hangs up when I think to myself, "gee it's been awhile since
it last hung up" and then proceed to travel at least three hours away
form the server, often far from connectivity or into exceptionally slow
or unreliable dial-up land.
I'll let you guys know as soon as I do (it does), however. __alarm__
messages without a corresponding freeze CONCERN me, but not NEARLY as
much as when the system is "of a down".
"__alarm__" without another warning explaining it immediately afterwards
are bad.
"__alarm__ignore__" are just timeouts that can be, well, ignored.
Daryl
