Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-13 23:57 UTC

Message

Re: [milter-greylist] NOQUEUE: Milter (greylist): to error state

2018-03-20 by Christian Pélissier

Le vendredi 16 mars 2018 � 17:40 +0100, John Damm S�rensen
john@... [milter-greylist] a �crit :
>   
> 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.



After checking many things, logs "NOQUEUE to error state" are related to
nagios monitoring.
/usr/lib64/nagios/plugins/check_nrpe -H $IP -c check_mailq -t 10




> 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
> > 
> > 
> > 
> > 
> 
> 
> 
> Virusfri. www.avast.com 
> 
> 
> 

-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.