サーバーには、いくつかのファイルを生成し、/tmp完了したら削除しない通常の操作があります。入力したくない理由でジョブを変更してファイルを削除することはできません。だから、定期的にこれらのファイルを削除するcronjobを作成したいと思います。ジョブの実行を妨げないようにするには、1日後のファイルのみを削除する必要があります。私は次のコマンドを思い出しました。
find /tmp/myprefix* -mtime +1 -delete
端末でテストするとうまくいくので、cronで予約します。
0 1 * * * find /tmp/myprefix* -mtime +1 -delete
午前1時に実行すると、パラメータを-mtime無視してから始まるすべてのファイルを削除して、myprefix実行中のタスクを妨げるようです。
なぜこれが起こるのか知っている人がいますか？
注：タスクは夜間のみ実行されるため、タスクを実行せずにすべてのテストが実行されます。昨夜完了した作業のファイルがまだそこにあることを確認しました。たぶんそれが理由であり、ファイルがまだ記録されている間にファイル修正時間が奇妙な方法で設定されているのでしょうか？
日中に清掃を予約することは確実な解決策であることがわかりますが、それでも問題の原因に興味があります。
編集する
Kusalanandasの提案に従って、昨夜のクローンエントリを次のように変更しました。
0 1 * * * find /tmp/myprefix* -mtime +1 -ls > /tmp/find.out
/tmp/find.out今朝はファイルが空でした。これは古いファイルがないために予想される動作です。しかし、過去の観察によると、-delete「あまりにも若い」ファイルで実行すると削除されます。
編集2
最後のテストを終えた後、2番目の夜のコマンドを次に変更しました。
0 1 * * * find /tmp/myprefix* -mtime +2 -delete
予想通り、+2前日の夜に作成されたファイルは削除されませんでした。ファイルは残っていましたが、今夜のファイルは削除されました。これで-mtime、ファイルがまだ作成されている場合は、スキャンが期待どおりに実行されないと確信しています。-ls前日の夜に何も出力されなかった理由は依然として謎です。たぶんもう一度実行して、-exec詳細lsを学ぶ必要があります。ところで2週間の休暇を控えてもう一度挑戦してみましょう:-)
答え1
cronエントリは別のbash行のように見えますが、そうではありません。 find構文を別のスクリプトに入れて実行してみてください。たとえば、次のようになります。
echo "find /tmp/myprefix* -mtime +1 -delete" > /my/path/cronscript.sh chmod 755 /my/path/cronscript.sh
cron 行を次のように編集します。0 1 * * * /my/path/cronscript.sh
いくつかの調整も必要な場合があります。chown / chgrpまた/etc/crontab、アーカイブで作業している場合は、username追加情報が必要です。0 1 * * * username /my/path/cronscript.sh