私は解決策があると思いますが、半分だけテストしました。残念ながら、私のシステムにそのデバイスがないのでテストすることができず/dev/xconsole、それが何であるかもしれないし、見る時間もないことを認めます。

しかし、2つの利点があります。まず、以下の方法は一般的です。つまり、/dev/xconsole私が使用したもの以外のファイル名をほぼ確実に使用できます。第二に、私はただDebian Busterでテストしたので、実際にはすぐに動作します。

まず、（非常に簡単な）解決策を紹介し、どのように動作するかを説明し、いくつかの考えられる問題とそれを回避する方法を紹介します。

解決策

注意事項としてまず保有していることを確認してください/usr/sbin/sendmail。これはしなければならないいいえそうですね。このプログラムは通常MTAに属していますが、MTAがインストールされていないと言われています。存在する場合は、含まれているパッケージを削除します。

/usr/sbin/sendmail次に、次の内容でスクリプトを作成します。

#!/bin/bash
cat >>/root/result

それに応じて権限を設定します。

chmod a+rx,u+w,og-w /usr/sbin/sendmail

再起動cron:

systemctl restart cron

それだけです。。cron通常、電子メールを介して送信されるすべてのエラーメッセージはここに入ります/root/result。

もちろん、上記の手順はrootユーザーとして実行する必要があります。

/root/resultあなたの場合は、おそらく次のように変更したいと思います/dev/xconsole（しかし、上記のようにこれをテストしていないことに注意してください：-））。そして結局は次のよう>>に置き換えなければなり>ません（しかし私はそれについて全く知らないので/dev/xconsole、この内容は間違っているかもしれません。）

どのように動作しますか？

定義：以下では、SENDMAILを使用してSENDMAILパッケージを参照し、sendmailアプリケーションを参照します。

電子メールメッセージを送信するほとんど（または少なくとも多くの）プログラムは、ソケットまたはネットワーク接続を介してMTAと直接通信する必要があるSMTPプロトコルスタックをデフォルトで実装せず、セキュリティの観点からSMTPライブラリを含めません。間違いは致命的であり、ほとんどの場合、特別なアプリケーションが救出されるので、これは必要ありません。

これらの特別なアプリの1つは、/usr/bin/sendmailSMTPなどが含まれており、非常に使いやすいということです。一般的なパターンは次のとおりです。

cat MyMailMessage | /usr/bin/sendmail [sendmail-options]
# OR, even shorter
/usr/bin/sendmail <MyMailMessage

つまり、アプリケーションはメールメッセージを構成し（いくつかのヘッダーと本文のみを必要とするため、非常に簡単です）、それをサーバーにパイプし、sendmailサーバーは再びSMTP魔法を実行します。

歴史的に、SENDMAILはかつて基本的なMTAでした。 SENDMAILにはMTAだけでなく、MSP（Message Submission Program）も含まれています。 MSP部分は/usr/sbin/sendmail長い間SENDMAILを削除することができなかったため、多くのアプリケーションは実際にはまだメール送信者として機能するか、依存してい/usr/sbin/sendmailました。sendmailそのため、SENDMAILの競合他社（POSTFIXなど）でも、このプログラムを互換性ラッパーとして提供しています。

cronこの点で、その動作は他のアプリケーションと同様です。 SMTPをサポートしていません。代わりにsendmail実際にメッセージを送信することに依存します。ヘッダーと本文を含む生メッセージを構成し、sendmail実際に送信するようにパイプされます。

/usr/sbin/sendmailだから私は上記のスクリプトに置き換えました（MTAをインストールしたので、これは単にテスト用でした）。電子メールを送信しようとするとcron呼び出される/usr/sbin/sendmailこれが私たちのスクリプトです。スクリプトは単に標準入力を受け取り、ファイルにリダイレクトします。

ちなみに、cron元の電子メールメッセージを直接ここにパイプするのかsendmail、それとも最初に一時ファイルに入れてから、そのファイルからリダイレクト呼び出しをするのかsendmail、stdinそれとも別の操作を実行するのか、実際にはわかりません。

しかし、ここではこれは重要ではありません。重要なのは、それぞれの場合に元の電子メールメッセージが で構成され、 の に保存されることですcron(ただし、cronこれを行うことができます)。sendmailstdin

欠点、問題、改善点

catスクリプト内での使用は、効率性の点で最良の選択ではないかもしれませんが、予想される出力に依存します。スクリプトをファイルに配置する最良の方法を説明する多数の記事がありますstdin。これはあなたの質問の範囲に含まれていないようです。

私の解決策の1つの欠点は明らかです。 「実際」が必要な場合は/usr/sbin/sendmail問題があります。微妙なものを想像できます。見つかったかどうかに応じて動作するいくつかのアプリケーションがあるかもしれません/usr/sbin/sendmail。

たとえば、アプリケーションが実行可能ファイルを検出した場合はエラーを電子メールで送信することを決定でき、そうでない場合はログファイルにエラーを記録できます。これでアプリケーションの動作が変わります。次のことは状況によって大きく異なります。まず、一般的な場所ではエラーメッセージが見つからない可能性があります。第二に、sendmailこれは単純なスクリプトであり、アプリケーションが期待どおりに機能しないため、奇妙なことが発生する可能性があります。

しかし、解決策があります。再コンパイルを許可すると言われましたcron。私はソースコードにそれが使用するMSP名の定義がconfig.hあると信じています（しかし、今は確認できません）。#define解決策は明らかです。スクリプトの名前を次のように変更し、abcd1234それを値として使用するか#define、おそらくより良い方法で、スクリプトを別のディレクトリに配置します。いいえシステムの検索パスからスクリプトのフルパスを#define。

これは別の#define;しかし、スクリプトは単に無視するので、スクリプトに害を及ぼすことはありません。おそらく、cronスクリプトと直接エラー出力を目的のファイルまたはデバイスに直接ダンプすることもできます。これが可能かどうかを判断するには、ソースコードの追加分析が必要ですが、まだ実行していません。私は何が起こってもスクリプトに固執します。 1つの大きな理由は、次の段落を参照してください。

[2021年10月20日更新：

2021年10月20日、元の質問に対する私の意見で述べたように、再コンパイルを防ぐことができる問題を解決する代替方法があります。 「実際」をsendmail別の場所に移動し、その場所にスクリプトをインストールすることです。次に、スクリプトが実行されるたびに誰が呼び出したかを調べます。呼び出された場合はcron上記のように機能し、そうでない場合はsendmail同じ引数、つまりstdin「relay」と「real」stdinを使用して「real」を呼び出すようにしますsendmail。

]

別の問題は、興味のあるエラーメッセージが表示されるだけでなく、それを見るたびにヘッダーを含む元のcron電子メール全体が送信されることです。回避策は、使用やgrep友達sedなど、興味のない行をフィルタリングするいくつかのコードをスクリプトに追加することです。しかし、それもこの質問の範囲外です。