Automated SMTP Server Check

Home » CentOS » Automated SMTP Server Check
CentOS 15 Comments

I would like to set up a cron job to automatically check whether my mailserver and webserver are up, and tell me if they’re not.

This script tells me if my webserver is up:

#!/bin/bash wget -q –tries –timeout –spider http://melvilletheatre.com if [[ $? -eq 0 ]]; then
echo “Online”
else
echo “Offline”
fi

How can I do the something similar with my mailserver?

Or if someone knows of an integrated tool that will monitor this in a better way (whatever that may be), I’m more than interested.

15 thoughts on - Automated SMTP Server Check

  • No server listening at 10.0.129.71
    $ nc 10.0.129.71 25 << EOF QUIT EOF $ echo $? 1 Server listening at localhost $ nc localhost 25 << EOF QUIT EOF 220 sclark66.netwolves.com ESMTP Sendmail 8.14.4/8.14.4; Tue, 4 Nov 2014 15:03:22 -0500 221 2.0.0 sclark66.netwolves.com closing connection $ echo $? 0 -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com

  • Overkill for one or a few sites, but:
    http://www.opennms.org/
    can monitor most network services with a framework for alarms and notifications, plus keeping nice graph histories of snmp data
    (interface traffic, cpu/disk/memory use, etc.

  • Am 04.11.2014 um 20:36 schrieb Frank Cox :

    mon – old lady but small:

    $ yum -y install epel-release ; yum install mon

    $ rpm -qi mon |grep -E ‘Size|Summary’
    Size : 1155876
    Summary : General-purpose resource monitoring system

    $ rpm -ql mon | grep -E ‘http|imap|smtp|pop&or$’
    /usr/lib64/mon/mon.d/http.monitor
    /usr/lib64/mon/mon.d/http_tppnp.monitor
    /usr/lib64/mon/mon.d/imap.monitor
    /usr/lib64/mon/mon.d/phttp.monitor
    /usr/lib64/mon/mon.d/smtp.monitor
    /usr/lib64/mon/mon.d/smtp3.monitor

    $ vi /etc/mon/mon.cf

    $ service mon start

    $ monshow

    and if you like (on EL{5,6}):

    $ chkconfig mon on

  • It looks really cool, but boy does it have a list of dependencies:

    fping is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Authen::PAM) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Authen::Radius) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(CGI) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(DBI) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Expect) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Mon::Client) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::DNS) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::DNS::Packet) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::DNS::RR) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::DNS::Resolver) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::LDAP) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::SNPP) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Net::Telnet) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(SNMP) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(SNMP) >= 1.8 is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Statistics::Descriptive) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Sys::Syslog) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Time::HiRes) is needed by mon-1.2.0-8.el7.CentOS.x86_64
    perl(Time::Period) is needed by mon-1.2.0-8.el7.CentOS.x86_64

  • It could be done using a crontab job and it’s very efficient sometimes to use only a crontab job instead of nagios.

    You can use the precompiled nagios scripts for the task. Unless you have constrains on the OS allowed languages and packages, which then should be evaluated more deeply to meet your needs which might be missing.

    So:
    – – Nagios scripts as crontab job
    – – Other tcp level scripts as a crontab job
    – – fully fledged nagios
    – – other relevant solutions in your scope

    Eliezer

    —–BEGIN PGP SIGNATURE—

  • I’d second nagios, but I think to -really- test SMTP, you’d need an external email source, a specialized target user and cron on both sides
    (at least that’d how I’d do it, just to be sure mail is really flowing through). I also don’t think cron for monitoring is a terribly good idea. and I think you also need to consider the implications of how you send out your alerts based on what you monitor. e.g. oh no .. email is down! quick! fetch me an admin; send an emai… d’oh!

  • …

    How about a cron job that e-mails you the output of ‘service httpd status’ or equivalent? You’ll get a message that tells you if your web server is up or not. If you don’t get a message, your mail server is down! (HHOS.)

    Unless you’re just collecting performance or availability metrics for reports, how you intend to be notified is something to consider. It’s trivial to have a web server’s failing check result e-mailed to you, but you need an out-of-band notification method (an old Nokia phone attached to the serial port that emits an SMS message, for example) if your mail server is having difficulty.

  • It’s a Perl program designed to test a bunch of different services. Of course it’s going to require the Perl modules needed to do those queries.

  • For just testing whether the SMTP server is up (which is what the OP
    originally requested) a nagios check may be sufficient. As another poster mentioned, he could use the check_smtp plugin (e.g., via cron, though I agree with you that cron isn’t a great tool for monitoring)
    without running a full Nagios server.

    For verifying that delivery is occuring successfully, you’d need more what you described, but even that’s not going to be foolproof: maybe delivery to you is working fine, but delivery to other users isn’t working properly. It’s really up to the OP, how much work does he really want to put in?

    –keith

  • For some fast and free monitoring along with DNS
    verification/blacklist/config checks of your MX records, MXToolbox lets you monitor one domain for free. Nice to have an external, independent source checking your public MTA. Nagios is still what I
    would choose for minute-by-minute checks but MXToolbox is free, and isn’t tied to your infrastructure in any way.

  • I know we’re getting a littl off topic, so I’ll ask first: there are a bunch of external services I use to monitor things like DNS and SMTP
    which are difficult to get a true handle on from the inside. Is it too off-topic to talk about some of these resources on list?

    (MXToolbox looks pretty interesting, I’ll look into it for myself later.)

    –keith

  • If you want to run your own – and have remote systems to handle it, opennms can run remote monitor agents (via java remoting) that report back to the central server.