1

RHEL 5

I'm using a perl service monitoring script (written by a colleague that is no longer with the company) running on an old RHEL 5 box. If a service is down, it sends an email alert to the root user:

            # Email administrator
            if ($retval == 0 && $config{'MAX_EMAILS'} > 0) {
                $service_restarts{$service} = 0;
                system("echo \"This notification was generated because $service was down and has been successfully restarted.\"
 | /bin/mail -s \"Monitor: $service restarted ($date)\" root");
            }

In /etc/aliases I have:

root:            fooadmin@fooexample.blah

My question is -- what services need to be running in order for mail sent to root to get relayed to the external alias? If those services are down, will /usr/bin/mail queue?

3

mail is pretty dumb and usually just lobs the message off to a sendmail binary. Unfortunately there are multiple implementations of mail so you'd ideally need to inspect the docs or code to see what sort of error handling (if any) is done for the exact version in use.

In addition to the mail service that sendmail is part of—Mail Transport Agents (MTA) which on RHEL5 would most likely be Sendmail or Postfix—you will likely also need DNS as the MTA will need to perform a DNS lookup on fooexample.blah to be able to send there. Possibly also a MTA queue runner if there's a temporary failure and the email ends up in a MTA queue directory somewhere (RHEL MTA include such queue runners by default). Oh, and a filesystem, if /var or whatever is full the MTA will probably not be able to queue additional mails and therefore will likely not accept the message from mail. (Especially if due to some other error the alert system fills up /var and then more alerts are created and then when it unbreaks you have to call the pager company because they disabled your pager because it got sent a bazillion alerts and oh I so do not miss those days.)

... and a working network, depending on how broadly you want to define service ... and also there are optional but commonly used anti-spam services; what happens when Gmail or Exchange are rejecting or discarding your alerts as spam?

Also do note the lack of error checking on that system call; mail (or a fork or exec call) could fail, and then what? Slightly more sensible may be to log such failures somewhere:

use Sys::Syslog;
openlog("homegrown-monitoring-101", "ndelay", "user");

system("echo ... root") == 0
  or syslog(LOG_ERR, "non-zero exit code from mail command");

And then ideally have something like sec.pl check for homegrown-monitoring-101 logs and report on them (via a grouped summary, not the usual cron spam of one email per log message...).

mail or the MTA may also leave dead.letter files somewhere (assuming it can write to where it wants to write those) which monitoring in theory could check for, but if there's a new dead.letter and your alerting is via email, you probably need some other protocol to report that error.

On centos 7 systems I instead use the perl-Email-Sender package over mail to lob messages places:

#!/usr/bin/perl
use 5.16.0;
use warnings;
use Email::Sender::Simple qw(sendmail);
use Email::Simple;
use Email::Simple::Creator;

...

my $message = ...;
my $email = Email::Simple->create(
    header => [
        To      => $username . '@example.edu',
        From    => 'nobody@example.edu',
        Subject => "...",
    ],
    body => $message,
);
sendmail($email);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.