syslog.1いくつかのメッセージがいっぱいで、77 GBのサイズのファイルを空にしようとしています。私がやった
sudo truncate -s 0 /var/log/syslog.1
ただし、コマンドが返されるまでに2時間以上かかります。 Ctrl-Cまたはkillコマンドで停止しても安全ですか？これらの方法により、ファイルシステムの不一致が発生する可能性があります。もっと良い方法がありますか？
システムはUbuntu 16.04です。ファイルサイズが突然増加し、そのファイルを含むルートパーティションが/var/log/syslog.1ほぼいっぱいになりました。後続のファイルは拡大し続けますが、コマンドラインはまだ応答します。/var/log/syslog/var/log/kern.log
ベストアンサー1
プロセスを中断しても、ファイルシステム自体は破損しません。カーネルはこれを保証します。最悪のシナリオは、ファイルがアプリケーションの不変性に関して一貫性のない状態にあることです。たとえば、ファイルの保存中にファイルエディタを終了すると、半分だけ作成されたファイルが残る可能性がありますが、他のファイルは破損しません。
このtruncateユーティリティはftruncate後ろからシステムコールを呼び出します。このシステムコールはアトミックです。発生または発生しません。したがって、プロセスを終了すると、truncate最終結果はファイルがtruncateまだ実行されていないかのように元の状態に保たれるか、ファイルが切り捨てられることです。短縮されたが完全に切り捨てられていないファイルで終わることはできません。
ファイルを切り捨ててもディスク上のデータは上書きされません。ファイルの使用済みブロックリストと使用可能なブロックリストのみを更新します。データブロック自体は更新されません。後でデータを保存するためにリサイクルされたときに上書きされます。ファイルが大きい場合でも時間がかかりません。 77 GBのログを保存できるスペースがあるハードウェアでは、77 GBのデータを上書きするのに数時間かかることはありません。だから何か悪いことが起こった可能性が高いです。ディスク全体でパフォーマンスが低下する病理学的ケースがあるかもしれませんが、それでもシステムは数秒遅くなると予想しています。優先順位の高いディスクに異なる書き込み操作があると、数時間ではなく数分かかることがあります。 。より可能性の高い可能性は、ディスクに問題があるということですが、これは主に偶然の一致です。カーネルログを確認してください。ディスクに問題がある場合は、そのメッセージが表示されます。ディスクの状態も確認してくださいインテリジェント制御。
ちなみに、syslog.1このファイルはアーカイブファイルなので、他の内容は記録されません。空にするよりも削除する方が良いです。
カーネルやハードウェアのエラーがない限り、これはプロセスが終了したかどうかに関係なく発生する可能性があります。