Re: [exim] Exim 4.66 Causing Kernel Panics?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] Exim 4.66 Causing Kernel Panics?
Don O'Neil wrote:
> Anyone aware of a reason why a fresh build/install of exim 4.66 would cause
> kernel panics and reboots on my FreeBSD 6.1 machine?
>
> My machine, just out of the blue this morning, started rebooting every 3
> minutes.... I narrowed it down to exim I think... As long as I never started
> up exim 4.66 the machine didn't have the problem... But as soon as I started
> it up, whammo... Panic and reboot.
>
> I've since rolled back to 4.63 and the problem seems to be resolved at least
> for the moment.


I've never had a *BSD machine do anything like that. Even with broken builds.

Don't have that exact combo, but:

4.53 thru 4.66 on 4.11-STABLE VIA C3, Intel Celeron and P4, AMD Duron, Athlon

4.63 on 6.2 AMD-64 (Intel dual core CPU) [1]

4.65 on 6.2 AMD-64 (Intel dual core CPU)

>
> The strangest thing is that I upgraded to 4.66 several days ago and the
> problem didn't show up until this morning. I'm not 100% sure the problem is
> exim but that's the only thing I could narrow it down to. Perhaps there is a
> new exim bug/exploit that I just didn't get hit with until today? I deleted
> the message queue just in case it was corrupt.
>


We've been on 6.2 since PRE last year, and it went production 2 months ago, so I
would first suggest getting the OS up to date. dot one builds are usually
suspect on any OS...

;-)


> ANY ideas from anyone as to what could be causing this (hardware perhaps?)
> would be appreciated.
>
>


What do you find just before the reboot in /var/log/console.log, ~/messages,
~/maillog, ~/auth, security, etc etc.....

...and the Exim log set, particularly ~/paniclog?

Are you using portaudit? chkrootkit? rkhunter? Running at kern_securelevel of 2
or better?

HTH,

Bill

[1] Hammered (in vain) by bots on the night of the 12th to the tune of 3.5
million lines of not-overly-verbose logging for 24 hrs, over 800,000 in the peak
hour alone. DID outrun PgSQL connections and defer some legit traffic - but ony
for a few minutes out of that peak. Still sorting hown many conections and
message attempts that represented, but box stayed calm throughout.

Ramped-up rejection settings to draconian on PTR fail et al, so problem solved.