66151


今、サーバー(ないし何かしらのプロセス)が延々とログを `/path/to/log`
に出力(append)しているとします。今、多少ログが崩れても良いからこのファイルを切り詰めたいと思いました。

# 質問

このようなとき、ファイルを切り詰める正しい方法は何ですか？  
切り詰めた後は、その `/path/to/log`
に対しての出力を引き続き行なって欲しいと考えているのですが、これはその出力を行なっているプロセスが、例えば素朴にファイルディスクリプタを開いてそれに対して延々
write
しているだけのようなプログラムであったとしても、問題なく行えますか？それともログ出力中のプロセスは、何かの例外からの復帰処理に対応している必要がありますか？


CC BY-SA 4.0
2020-04-29T16:35:40.237
66127
2020-04-30T10:23:25.130
754
question
linux
linux で追記され続けているログ的ファイルの truncate を行う方法は?


私は次の方法でログファイルを切り詰めています。

[code]

    cp  /dev/null ログファイル
    
[/code]

`bash`から

[code]

    > ログファイル
    
[/code]

で消すこともあります。

本当に大丈夫かはわかりませんが、これまで問題が発生したことはありませんでした。


CC BY-SA 4.0
2020-04-29T22:27:29.557
66130
2020-04-29T22:27:29.557
35558
66127
answer


linuxではlogrotateコマンドを用いてログを切替を実施したり、世代管理を実施する方法があります。logrotateコマンドはログを出力しているプロセスの外側からログを管理（リネーム、コピーなどなど）していきますが、もちろん銀の弾丸ではありません。一度開いたファイルポインタをそのまま持ちまわるようなプログラムだと、切替以降の書き込みで失敗することも想定されます。たとえばjavaのlog4jでは（おそらく特定の設定条件で）外部からファイル名の変更、削除、再作成などを経た場合に、ファイルに正しく書き込みできなくなっている事象を経験しました。つまり、logroteteは便利だけど、正しく運用するためには、ログを吐き出す側での正しい設計と実装が不可欠となるということです。

もともとログに何を期待しているの？という話もありますが、例えば法廷要件を満たすためにログを使用したいと考えている場合などは「ファイル」ではなくDBへの書き込み（失敗した場合のみエラーログを出力。エラーログの切替運用は行わない。）などの配慮が必要で、それは割とシステム要件によったりします。  
こうして考えると「ログファイル」は管理が面倒なので、最近のクラウドを前提とするような世界では、標準（エラー）出力に投げておくことを選択し、あとの管理はプラットフォーム側のロツールにゆだねることが多いようです（主観ですいません）。たとえば、AWSであれば、その後のことはcloud
watchにお願いしちゃうような使い方です。


CC BY-SA 4.0
2020-04-29T23:09:31.020
66131
2020-04-29T23:19:27.193
2020-04-29T23:19:27.193
10174
10174
66127
answer


ログファイルへ書き込むプロセスがログファイルを `open`(2) の `O_APPEND` でオープンして追記している、という前提でいいですか?
そうであれば、何らかの方法で該当ファイルのサイズを 0 にすれば大丈夫です。

既存ファイルのサイズを 0 にする方法は `open`(2) で `O_TRUNC` オプションを指定して書き込みオープンする、書き込みオープン後に
`ftruncate`(2) でサイズ 0 に変更する (もしくは `truncate`(2) でログファイル名を指定してサイズ 0 に変更する)
方法があります。

ほかの回答にある `cp /dev/null ログファイル名` や `>ログファイル名` は前者の `O_TRUNC`
で書き込みオープンして何も書き込まずクローズしている動作になります。

なお、ログを書き込むプロセスが `O_APPEND` でオープンしていない場合はログファイルのサイズを切り詰めることはできません。


CC BY-SA 4.0
2020-04-30T10:23:25.130
66151
2020-04-30T10:23:25.130
3061
66127
answer