The confMILTER_MACROS do not look sane; can you try

---
define(`confMILTER_MACROS_CONNECT', confMILTER_MACROS_CONNECT`, {daemon_port}')dnl
define(`confMILTER_MACROS_HELO',    confMILTER_MACROS_HELO`, {verify},{client_resolve}')dnl                                  
define(`confMILTER_MACROS_ENVRCPT', confMILTER_MACROS_ENVRCPT`,{client_resolve}')dnl                                                             ---                

Do you see segfault messages in 'dmesg' output?  Can you attach gdb to the running daemon (gdb /usr/sbin/milter-greylist `pidof milter-greylist` -> c) and provide the backtrace when it dies?

(In reply to comment #1)
> The confMILTER_MACROS do not look sane; can you try

Your configuration works. No more warning in the logs.

Perhaps it is advisable to amend the upstream "README" file, it is what I used for my config (/usr/share/doc/milter-greylist-4.2.2/README) and the upstream site also has wrong examples.

Do you know any alternative documentation source on this matter?


> Do you see segfault messages in 'dmesg' output?

Yep! There you go:
milter-greylist[15878]: segfault at 46 ip 0016fd17 sp b35fc2b0 error 4 in libc-2.10.1.so[110000+16b000]


>  Can you attach gdb to the
> running daemon (gdb /usr/sbin/milter-greylist `pidof milter-greylist` -> c) and
> provide the backtrace when it dies?  

Done! I'll let you know if it dies again.

I forgot: it would be nice when you install the milter-greylist-debuginfo and glibc-debuginfo packages.  They would improve backtrace significantly.

Indeed. :)

This bug report has been useful for me as well. Thanks for the work put into it.

One thing to note.... Before using the package provided by Fedora, I was using the package supplied by the author himself.

I had a very identical problem regarding milter-greylist crashing. The solution was to configure greylist.conf and sendmail to use an inet socket "inet:3333@localhost" (I really don't what that means, but it worked and milter-greylist stopped crashing).

However, in Fedora 11 the particular configuration that I'm mentioning produces an unsafe socket error.

So I've had to revert to the orginal socket in a file

For now its working. If it crashes I will also let you know

Thanks Enrico!
The milter has been running perfectly with the configuration you posted.
I'll keep GDB attached for one more month, just in case, then I'll consider the case closed.

I also have this problem and will try to generate a backtrace when it crashes.

I also have similar config lines in sendmail.mc but I will not change these until I catched the crash.

(In reply to comment #1)

> Do you see segfault messages in 'dmesg' output?  Can you attach gdb to the
> running daemon (gdb /usr/sbin/milter-greylist `pidof milter-greylist` -> c) and
> provide the backtrace when it dies?  

Which commands should I run in gdb to get the right backtrace?
At the moment I have run the command mentioned above and then `cont` to let the program continue.

bt
info locals
info threads

Just a note we are seeing this on kernel.org as well, needless to say I'm a little annoyed at the problem.  Symptoms seem to be similar to this, we are running Fedora 11.

Speaking to the segfaults: yes we are seeing them:

Jan  9 21:04:00 hera klogd: milter-greylist[19382]: segfault at 0 ip 000000324e465b84 sp 00007fae3a1fafe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:05:54 hera klogd: milter-greylist[19756]: segfault at 0 ip 000000324e465b84 sp 00007f386a2d0fe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:11:57 hera klogd: milter-greylist[30571]: segfault at 0 ip 000000324e465b84 sp 00007fce0abfbfe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:24:25 hera klogd: milter-greylist[12866]: segfault at 0 ip 000000324e465b84 sp 00007f6da17f9fe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:28:53 hera klogd: milter-greylist[18770]: segfault at 0 ip 000000324e465b84 sp 00007f9b8fffdfe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:32:46 hera klogd: milter-greylist[23600]: segfault at 0 ip 000000324e465b84 sp 00007f2654df8fe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:34:00 hera klogd: milter-greylist[24017]: segfault at 0 ip 000000324e465b84 sp 00007ffb93ffdfe0 error 4 in libc-2.10.2.so[324e400000+164000]
Jan  9 21:34:45 hera klogd: milter-greylist[24170]: segfault at 0 ip 000000324e465b84 sp 00007f4b961fafe0 error 4 in libc-2.10.2.so[324e400000+164000]

Not keen to attach gdb if I don't have to, but I would appreciate an escalation on this bug.

sorry, I lost overview about update state of my packages and did not noticed that there was sitting an unfiled version of milter-greylist in koji.  Please try

  https://admin.fedoraproject.org/updates/milter-greylist-4.2.3-1.fc11

Problem is ongoing with the milter-greylist from koji, seeing the failure every few hours right now.  We've added a cron job that checks for the services availability and restarts it should it fail.

Here are steps that you can take to stop the crashing if you have version 4.2.3

------------------------------------------------
Modify your sendmail.mc and rebuild sendmail.cf
------------------------------------------------
So that the line refering to milter-greylist reads something like the following.

INPUT_MAIL_FILTER(`greylist',`S=inet:3333@localhost, F=T, T=S:1m;R:2m;E:3m')


------------------------------------------------
Modify /etc/mail/greylist.conf
------------------------------------------------
so the line that refers to which socket to use reads the following socket "inet:3333@localhost"


Make the above changes should end milter-greylist from crashing. Of course you will need to restart sendmail and milter-greylist. You may need to reboot the system to get things working.

J.H, I do not have enough information to track this down.  Crash address in comment #10 might be in _IO_fclose() where the FILE* ptr is dereferenced but I am not sure whether I calculated the offset correctly.  Nevertheless, I require the backtrace to do anything.

afais, 'fclose()' will be used only for

  stat ">>..."

statements.  Do you have such a statement in your configuration?  When yes, does the crash still happen when you replace it with

  stat "|cat >>..."

?

milter-greylist-4.2.3-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update milter-greylist'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0386

I've been using the update for quite sometime. Works great with inet socket

ok; I saw two of these segfaults (they happened on CentOS5 in strcmp()) in the last two months on one of my MTAs.  Both have in common, that a host established two connections (both from different senders and to different recipients) at (nearly) the same time.

I call 'milter-greylist' now through 'catchsegv' to detect the caller of the strcmp() but this can take some time...

it might be related to GeoIP  code; e.g. I see

| Error Traversing Database for ipnum = 3645194514 - Perhaps database is corrupt?
| *** Segmentation fault
| Register dump:

The 'Error Traversing Database' message is coming from libGeoIP and the strcmp() causing the segfault seems to be in geoip_filter().

The mentioned 'ipnum' is a host which connected twice within a short timeframe.

It might be, that GeoIP calls must be locked...  Will have to investigate this further.

please try builds from

http://koji.fedoraproject.org/koji/buildinfo?buildID=157731
http://koji.fedoraproject.org/koji/buildinfo?buildID=157730


They fix reentrancy problems in geoip (causes segfaults), p0f (causes missing results) and dkim code (not active).

milter-greylist-4.2.3-1100.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/milter-greylist-4.2.3-1100.fc11

milter-greylist-4.2.3-1100.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update milter-greylist'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-2491

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I know this is so old but is there a reason we are seeing this warning in the logs?
milter-greylist: smfi_getsymval failed for {daemon_port}, using default smtp port

rpm -q spamassassin
spamassassin-3.4.1-9.fc25.x86_64


rpm -q spamass-milter
spamass-milter-0.4.0-7.fc25.x86_64

I see a suggestion here: http://milter-greylist.yahoogroups.narkive.com/je9bHmdG/p0f-error-smfi-getsymval-failed

"Then make sure the daemon_port macro is exported to milter-greylist. You
must have a line like this in sendmail.cf:
O Milter.macros.connect=H, j, _, {daemon_name}, {daemon_port},
{if_name}, {if_addr}, {client_addr}"

but how do we get this in the sendmail.mc file?

(In reply to RobbieTheK from comment #26)
> I see a suggestion here:
> http://milter-greylist.yahoogroups.narkive.com/je9bHmdG/p0f-error-smfi-
> getsymval-failed
> 
> "Then make sure the daemon_port macro is exported to milter-greylist. You
> must have a line like this in sendmail.cf:
> O Milter.macros.connect=H, j, _, {daemon_name}, {daemon_port},
> {if_name}, {if_addr}, {client_addr}"
> 
> but how do we get this in the sendmail.mc file?

Something like this:

define(`confMILTER_MACROS_CONNECT',`H, j, _, {daemon_name}, {daemon_port},{if_name}, {if_addr}, {client_addr}')dnl

Thanks for the quick reply. We currently have these lines. Is it allowed to have this twice? Would I just add the capital H and  {client_addr}?

dnl #define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')dnl
define(`confMILTER_MACROS_CONNECT', confMILTER_MACROS_CONNECT`, {daemon_port}')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl

(In reply to RobbieTheK from comment #28)
> Thanks for the quick reply. We currently have these lines. Is it allowed to
> have this twice? Would I just add the capital H and  {client_addr}?
> 
> define(`confMILTER_MACROS_CONNECT', confMILTER_MACROS_CONNECT`, {daemon_port}')dnl
> define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl

The second definition here has overridden the first one. The first one adds {daemon_port} to the default value (and that's the same line I use on my own mail server). The second one completely replaces the previous value with "t, b, j, _, {daemon_name}, {if_name}, {if_addr}".

I would first try just removing or commenting out (with dnl) the last one and see if the first one works for you. If it doesn't, just add {daemon_port} to the list of macros in the last definition.