[opendmarc-users] opendmarc crash

[Murray S. Kucherawy]

On Wed, 13 Mar 2013, Andrei Ioachim wrote:
> Mar 13 11:02:47 main postfix/smtpd[21545]: connect from unknown[unknown]
> Mar 13 11:02:47 main postfix/smtpd[21545]: warning: milter 
> inet:localhost:8893: can't read SMFIC_CONNECT reply packet header: Success
> Mar 13 11:02:47 main postfix/smtpd[21545]: lost connection after CONNECT from 
> unknown[unknown]
> Mar 13 11:02:47 main postfix/smtpd[21545]: disconnect from unknown[unknown]
>
> after "connect from unknown" dmarc in dead
>
> (opendkim doesn't seem to have a problem with "unknown")

I believe opendkim had this problem at some time in the past and it was 
fixed, but since the opendmarc code is based on the opendkim code, it 
should have inherited the fix.

> Mar 13 11:04:14 main postfix/smtpd[21545]: warning: connect to Milter service 
> inet:localhost:8893: Connection refused
>
> i've tried Milterdebug 9 and i don't see something new in logs
> it should go to the same syslog right?

Yes, they should log to the same place.

> i've tried enablecoredumps and i don't see any dumps
> is there a specific location where i should look for the dumps?

All things being equal, the core would appear in the current working 
directory of the filter when it crashes.  However, there are a few things 
that can affect core dump generation:

- core dump size limit in your shell
- write permission to the current working directory of the process
- enough disk space or disk quota
- whether the process has called setuid()
- kernel flags can adjust the location of a core dump

Check the core(5) man page for information on your local system's rules.

Another thing that might help is to compile opendmarc such that the debug 
flags are on and the optimize flags are off, run it inside gdb until it 
crashes, and then use gdb commands to extract a stack trace and figure out 
what broke.

-MSK