私は、Linux のコマンド ラインで完璧に動作する Perl スクリプト (Vicidial ダイヤラー ソフトウェアに付属) を持っています。スクリプトの最後に電子メールが送信されます。
スクリプトはエラーを生成せず、sendmailまでのスクリプト全体は(https://metacpan.org/pod/Mail::Sendmail) 関数は、crontab およびシェル スクリプト実行可能ファイル (root として実行) で実行すると正常に動作しますが、電子メールは送信されません。
bash 実行可能ファイルと bash CLI でスクリプトを実行する場合の違いは何ですか? sendmail 関数はエラーをスローしませんが、なぜ送信されないのでしょうか?
以下は、Perl スクリプトからの関連するコード スニペット 2 つです。
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;
}
スクリプトを実行する方法は次のとおりです。
/usr/share/astguiclient/AST_email_web_report.pl --email-subject=XXXX--email-list=XXXX --email-sender=XXXX --date=XXXX
答え1
一般的に言えば、「あるユーザーのシェルでは動作するが、crontab
(または別のユーザーのシェルでは)動作しない」というのは、プログラムが環境設定(多くの場合)に依存していることが原因で、PATH
最初のユーザーが設定した環境設定cron
と他のユーザーのシェルでは設定が異なっていたり、設定が欠落していることを意味します。
私があなたが説明したような状況に陥った場合、まず Perl コードを確認します。Perl は私の得意分野ですから。そして、print "Back from sendmail\n";
の直後にコマンドを配置してsendmail(%mail) or die
、メールを送信しようとしたときにプログラムがサイレントに終了しないことを絶対に確認します。しかし、あなたはおそらく、これらの基本事項を可能な限りすでにカバーしていると思います。
次に、env
コマンドが機能するシェルでコマンドを実行し、出力を調べて関連している可能性のある設定があるかどうかを確認します。次に、それらの設定をルートのシェル環境に移植して、メールがそこで機能するかどうかを確認します。ルートで機能する設定を特定したら、同じ設定をファイルにも配置するとcrontab
、それも修正されるはずです。
調査できるもう 1 つの方法は、tail -f
メール サーバーのログを調べて、メッセージを受信してから破棄 (またはバウンス) しているかどうかを確認することですが、これは少し難しいように思われ、適切なメール サーバーのログにアクセスできる必要があります。失敗したメールの試行からバウンスを受信していない限り、環境の問題である可能性の方がはるかに高いようです (まだ行っていない場合は、ルートのメールボックスを確認してください)。
答え2
提供されたスクリプトにバグがあり、オプションがオンになるべきでないときにオンになる可能性があることを発見しました。現在はすべて正常に動作しています。