Milter-greylist

The sendmail code issuing the error message is in the milter_error() 
function which has this comment:

 ��� ��� /*
 ������� **� We could send a quit here but we may have gotten here due to
 ������� **� an I/O error so we don't want to try to make things worse.
 ������� */
So it might be useful to check the messages file for error messages 
related to general system starvation ( memory, file system, /tmp , etc.)

When everything else fails try run strace -o <output file> -tfp <pid of 
milter-greylist> and check for errors.

Best

John

Den 16-03-2018 kl. 17:00 skrev Christian P�lissier 
Christian.Pelissier@... [milter-greylist]:
>
> Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
> john@... [milter-greylist] a �crit :
> >
> > So both greylist and mimedefang fails. Do you see anything in the
> > logs? Are they failing on the same email maessage?
>
> Both have always the same sendmail PID 17925 in the example
> > How are they defined in the .cf/.mc file?
>
> Well ... I hope
>
> INPUT_MAIL_FILTER(`greylist', 
> `S=local:/var/milter-greylist/milter-greylist.sock, 
> T=C=6m;S:10m;R:10m;E:10m')dnl
> INPUT_MAIL_FILTER(`mimedefang', 
> `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, 
> T=S:360s;R:360s;E:15m')
>
> INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
>
> I can try to use an inet socket, but I have other milter with local
> socket and they do not log NOQUEUE messages.
>
> Milter API evolved with time. Could we have both in mimedefang and
> milter-greylist and old style milter callback indirectly related with
> theses log lines ??
>
> Another cause (the stange period of 5mn) could be a nagios monitoring
> occuring regularly but in that case why only 2 milters are affected ?
>
> I found inside sendmail source and KNOWBUGS file a bug related to
> NOQUEUE: but not related with milter
>
> =====
> * accept() problem on Linux.
>
> The accept() in sendmail daemon loop can return ETIMEDOUT. An
> error is reported to syslog:
>
> Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
> getrequests: accept: Connection timed out
>
> "Connection timed out" is not documented as a valid return from
> accept(2) and this was believed to be a bug in the Linux kernel.
> Later information from the Linux kernel group states that Linux
> 2.0 kernels follow RFC1122 while sendmail follows the original BSD
> (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels
> will follow the POSIX draft.
> =====
>
> I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and I
> have no such message
> >
> > /john
> >
> >
> >
> > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> > Christian.Pelissier@... [milter-greylist]:
> >
> > >
> > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > > john@... [milter-greylist] a �crit :
> > > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > >
> > > I have no 10s timeout. I've changed C:5m to c:6m. Logging period is
> > > always 5mn.
> > >
> > > Mimedefang log the same thing at the same time but opendkim,
> > > opendmarc
> > > clamav do not log NOQUEUE message.
> > >
> > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist): to
> > > error state
> > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (mimedefang): to
> > > error state
> > >
> > > Opendkim and Opendmarc have default flags
> > >
> > > --
> > > Christian P�lissier
> > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > \ue201 34419
> > >
> > >
> > >
> > >
> >
> >
> >
> > Virusfri. www.avast.com
> >
> >
> >
>
> -- 
> Christian P�lissier
> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> \ue201 34419
>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus