cronスケジュールジョブを実行するためにfindを使用すると、奇妙な問題が発生しました。 ２つの操作が行われた。
- 最初の行は、「read_」で始まり、「.gz」で終わるファイルを毎晩3日以上削除する必要があります。
- 2行目は、「.gz.md5」で終わる1分より古いファイルを毎分削除する必要があります。
1 1 * * * find <path that defiantly does not match> -type f -iname "read_*.gz" -ctime +3 -delete
*/1 * * * * find <path that defiantly does not match> -type f -iname "*.gz.md5" -cmin +1 -delete
通常、これはうまくいきますが、時々01:01にcronで次のエラーメッセージが表示されます。
Cron <root@hostname> find <path that defiantly does not match> -type f -iname "read_*.gz" -mtime +3 -delete
find: ‘<path that defiantly does not match>/<hostname>/captured-syslog-1617836127-1617836351.gz.md5’: No such file or directory
しかし、私の観点からは言葉ではありません。
ベストアンサー1
事実：01:01に、2つのジョブが同時に実行されていました。
前提：問題のファイルシステムはディレクトリエントリにファイル形式を保存しません。
考えられる説明
ある時点で、find調査中のファイルの種類を知る必要があります。明示的な-typeテストが理由になる可能性がありますが、それが存在しない場合でも（場合によってはそれ以前でも）ファイルがディレクトリであるかどうかをfind知る必要があります。ディレクトリの場合は、findそのディレクトリに削除されます。
あなたのファイルシステムがファイルタイプ情報をディレクトリエントリに保存していないようです。この場合、ファイルの種類を知りたい場合はfind呼び出しが必要ですlstat（常にそうではありませんが、いくつかの最適化を実行できます。参照）。この回答）、ファイルが存在する必要があります。
findファイルが特定のディレクトリにあることを知った後、他の人がファイルを削除した場合lstat、No such file or directoryあなたの場合には「他のもの」が別の作業です。
ファイルシステムがファイルタイプ情報をディレクトリエントリに格納する場合、状況は異なります。これは他の操作がファイルを削除した場合にのみ発生する可能性がありますが、以前-ctimeにテストされており、すべての可能な干渉をフィルタリングしたため、これは発生しません。-cminNo such file or directory-iname
私は実際にこのフラグを使用または使用せずに生成されたファイルシステムfindでGNUをテストしました。このフラグがないと、ファイルシステムはディレクトリエントリにファイル形式を保存しません。他のプロセスでファイルが作成され削除される状況をクリーンアップしました。これらのファイルは意図的にext4filetypeいいえ一致し-inameて一緒に使用してくださいfind。
filetypeそのフラグのないファイルシステムのテストで、find私が使用しているNo such file or directoryファイルと一致しないファイルに関する苦情が頻繁に発生しました。-inameテストに不満はありませんでしたfiletype find。