I have a Perl script (that came with my Vicidial dialer software) that runs perfectly in the Linux command line. It sends an email at the end of the script.

The script doesn't create any errors and the whole script up to the sendmail (https://metacpan.org/pod/Mail::Sendmail) function works correctly when run in crontab and in a shell script executable (running as root), however the email doesn't send.

What is the difference between running the script in a bash executable vs bash CLI? The sendmail function is not throwing any errors, why would it just not send?

Here are two relevant code snippets from the Perl script:

use MIME::QuotedPrint;
use MIME::Base64;
use Mail::Sendmail;
if (length($attachment)>0) {
    #print $mail{body};
    sendmail(%mail) or die $mail::Sendmail::error;
    #print "error: ";
    #print $mail::Sendmail::error;

This is how I run the script:

/usr/share/astguiclient/AST_email_web_report.pl --email-subject=XXXX--email-list=XXXX --email-sender=XXXX --date=XXXX

2 Answers 2


Generally speaking, "it works in one user's shell, but not from crontab (or in another user's shell)" means that the problem is caused by the program relying on environment settings (very often PATH) which the first user has in place, but are different or missing in the cron environment and the other user's shell.

If I were in the situation you describe, the first thing I would do is review the Perl code, because Perl is my thing, and then I'd put a print "Back from sendmail\n"; command immediately after the sendmail(%mail) or die, just to be absolutely certain that the program isn't exiting silently when attempting to send the mail. But I assume you've probably already covered those bases as well as you're able.

The next thing, then, is to run the env command in the shell that it works for and go through the output for any settings which look like they might be relevant, then try transplanting those settings into root's shell environment to see whether they get the mail working there. Once you've identified the setting(s) that get it working for root, then you can also put those same settings into the crontab file and it should fix that up, too.

Another avenue you could investigate would be to tail -f your mail server log to see whether it might be receiving the message and then discarding (or bouncing) it, but that seems like a bit of a long shot and requires you to have access to the appropriate mail server's logs. Environment issues seem much more likely, unless you're receiving bounces from the failed mail attempts. (Check root's mailbox for them if you haven't already done so!)

  • Thank you for your answer. As someone that has spent the last couple of days on this problem I can acknowledge that this is very good advice.
    – Tim O
    Jun 30, 2019 at 11:36

I discovered a bug in the provided script that allowed an option to be turned on when it shouldn't have been. Everything is now working normally.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .