私は、1時間ごとにファイルを開き、そのファイルに出力してファイルを閉じるという長時間実行されているスクリプトを持っています。最近、印刷が失敗することはめったにありません。印刷自体のステータスをテストしているためではなく、システムが実際に再起動されるまでファイル内のエントリが欠落しているためです。
私はファイルを開くのに失敗したことをトラップし、それが起こったときにsyslogにメッセージを書き込みますが、開いている失敗は見られないので、印刷が失敗している可能性があると推測しています。私は印刷の失敗をトラップしていません。ほとんどの人はトラップしていないと思いますが、今度はその1つの印刷を更新します。
一方、私の質問は、十分なディスクストレージがあり、追加モードで正常に開かれたファイルの競合がない場合に、どのような種類の状況で印刷ステートメントが失敗する可能性があるかを知っていますか？
メモリ不足（ENOMEM）またはファイルサイズ制限（E2BIGまたはSIGXFSZ）を超えている可能性があります。昔ながらのI/Oエラー（EIO）が発生する可能性があります。スクリプトが同時に実行されている場合、またはファイルがNFS経由でアクセスされている場合は、競合状態になる可能性があります。そしてもちろん、値を出力する式にエラーが発生する可能性があります。
私がかつて見たエキゾチックな原因は、CPUヒートシンクの障害が、sprintfの誤った障害につながる可能性があり、ファイル記述子へのガベージの書き込みなど、いくつかの驚くべき結果を引き起こす可能性があることです。
最後に、printはI/Oバッファにその内容を書き込むことが多いことを思い出してください。これは2つのことを意味します。（1）close（）の結果も確認する必要があります。（2）印刷しても、すぐにclose（）またはflush（）を実行しない場合、データはバッファリングされ、かなり後になるまで実際には書き込まれません（または、プロセスがひどく停止した場合はまったく書き込まれません）。