How to monitor sendmail, not the daemon itself

[dsm666]

The issue I am having is the mailserver keeps going down, and no emails are being sent. We have monitors watching the sendmail daemon process, but that doesn't necessarily mean that the mailserver is working.
The problem also is we can send emails, but it blocks all inbound traffic. We could have used our sitescope monitor to monitor sendmail and watch for replies but unfortunetely they block inbound emails.

 

[Annihilannic]

... and no emails are being sent. ...
The problem also is we can send emails, but it blocks all inbound traffic. ...

I'm confused... which exactly is your problem? You can't send? You can't receive? Or sometimes you can do one or the other but not both?



Annihilannic.

 

[dsm666]

I shouldn't have put that last paragraph in there.
The issue is we can't receive any emails generated by any of our scripts. I checked the sendmail process and it was running:
root 11547 1 0 Jan 13 ? 0:04 /usr/lib/sendmail -bd -q15m
smmsp 11549 1 0 Jan 13 ? 0:00 /usr/lib/sendmail -Ac -q15m

 

[elgrandeperro]

Did you check you mailqs? Did you check the mail logs?

A script would invoke sendmail direct, so it FIFOs. When it is happening, use mailx with the -v option to the same address to see what happens.

A monitor script would probably involve sendmail running AND making sure the queues are not overly large or long.

 

[Annihilannic]

And also perhaps checking whether you could connect to the sendmail port 21? Something like:

if echo QUIT | telnet localhost smtp 2> /dev/null | grep -q ^220
then
    continue
else
    echo port 21 is unavailable
fi

Annihilannic.

 

[elgrandeperro]

Port 25, BTW, 21 is telnet.

That would work if the app is connecting to the localhost port 25, but if it is using like mailx, this isn't the case because it invokes sendmail direct ( for the initial send).

 

[Annihilannic]

Err, actually, it's FTP's control port. But yeah, I got it wrong first and forgot to change it in both places... thanks!

Annihilannic.