rootcrontabにタスクを追加しました。
# crontab -l | tail -n 1
*/3,13,29,43 * * * * /root/bin/check_network.sh
#
ただし、通常のユーザーとして実行されているようですrwb。
このrwbアカウント（このrootアカウントではありません）はジョブの失敗に関する電子メールを受け取り、失敗の理由は次のとおりです。
/root/bin/check_network.sh: line 26: iw: command not found
しかし、もちろんiwそうでしたが、/use/sbin/iwそうではありませんrootでした$PATH。rwb
どうなりますか？ ！ルートクローンジョブをどのように実行しますか？
修正する
コマンドをからに変更するとうまくいくように見えるので、iwcronを実行するときに通常のbashウィンドウと比較すると/usr/sbin/iw少し違いがあります。$PATH
答え1
sucrontabを設定するときにrootを使用しましたか？
Debian 10 では、次のようにman crontab言います。
su（8）はcrontabを混乱させる可能性があるため、su（8）内で実行している場合は常に-uオプションを使用して安全な場所に配置する必要があります。
suDebian 10リリースでは、Debianはコードベースの以前のコマンドを削除し、shadow-utilsコードsuベースに移行しましたutil-linux。これにより微妙な変化が多く発生した。
Debian 10 のデフォルト設定を使用すると、複数のユーザーが root アクセスを持つことができ、必要に応じて root 権限を使用する際に独自の個人設定が適用されます。ただし、結果としてsuor を使用すると、sudo -s環境変数が不完全に変更されます。たとえば、rwb一般使用から一般使用に変換した後でも、環境変数の値はそのまま残ります。rootsuUSERrwb一部のプログラムとスクリプトはこの変数を使用してユーザーを識別します。
したがって、そこにあるファイルを見ると、cronジョブ定義が実際にではなくに/var/spool/cron/crontabsあることがわかります。実際には、まだルートではないプライベートcrontabファイルを編集しました。/var/spool/cron/crontabs/rwb/var/spool/cron/crontabs/root
「完全にルートになった」環境変数を完全に再初期化するには、su -またはを使用する必要がありますsudo -i。
答え2
あなたに問題があるようです。環境;特にcron。私は2-3の異なるディストリビューション（主にDebian）を台無しにしました。環境常に同じではありません。私はcronその環境が何であるかを知らせるためにいくつかのトリックを使用しました。
次の行（または同様の行）を次の行に追加しますcrontab。
@reboot /usr/bin/printenv > /home/my/cronenv.txt 2>&1
これを対話型シェルで報告された環境と比較します（bashこの場合）。
pi@4b:~ $ printenv
ご覧のとおり、これら2つの環境には大きな違いがあります。持つ環境変化のためのさまざまなソリューションcronしかし、私の目的に応じて、実行可能ファイル/コマンドへのフルパスを呼び出す習慣を挙げるだけで、環境へのほとんどの変更は必要ありませんcron。
WRTはroot's crontabユーザーのものとは異なりますcrontab。
pi@4b:~ $ sudo crontab -e
root crontabこれにより、以前と同様にまったく異なるバージョンが提供され、環境の違いを確認できますuser crontab。必要なときprintenvroot crontab権限の増加職場ではcron、行く方法。
一部のシステムでは異なる方法で処理できますが、私が知っているDebianベースのシステムではうまく機能します。ジョブ/スクリプトを として実行しているので、sudo権限昇格を入力する必要はありません。root crontabcronroot