Re: Opendkim receiving SIGABRT

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Tue, 4 Sep 2012 15:53:01 -0700 (PDT)

On Tue, 4 Sep 2012, Marcelo Vieira wrote:
> I made the configuration you suggested, setting core dumps enabled and
> using debug binary. The crash did not occur for a few days, but recently
> we noticed it happened again. I did not find any additional information
> about this, and there was not any dump created. Am I missing something?

Did you change your process coredump size to be unlimited? If you've done
that and everything else I suggested, you should be getting core dumps on
crashes. Someone else familiar with your OS (which one is it?) would have
to give you further guidance.

If that still doesn't work, you have a couple of options:

1) If you're using sendmail as your MTA, configure it to quarantine
messages that are being handled when a filter crashes. Look in the
sendmail source code's TRACEFLAGS file for the exact setting to do this.
If you're using postfix, you could ask them if they have a similar capture
feature.

2) Disable "RunAsUser" if you're using it, and instead start the filter as
the intended user yourself. Linux at least, and possibly others, will
refuse to dump a core for a process that has changed userid.

3) Run the filter inside gdb with AutoRestart and Background disabled.
When it crashes, the debugger will capture the failure and you can walk
around in the code looking for the cause. Knowing how to use gdb is a
big plus here, otherwise you have to keep that process open until someone
with gdb tells you which commands to run.

> We also noticed that at the time de process crashes, in the syslog there was
> a lot of log entries for bad singature data, Is this the case when when the
> message was modified after signing and before verifying?:
>
> opendkim[24429]: CE60C8007E: bad signature data

Yes, though this by itself shouldn't cause a crash even if a lot of them
are happening at once.

The Erlang code is fairly new. Are you actually using it?

-MSK
Received on Tue Sep 04 2012 - 22:53:23 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:43 PST