シナリオは昨日、APIのバグをチェックする必要があったのと同じです。だからログサーバーにログインしました。後でタスクに再接続できるようにtmuxセッションを開きました。
デバッグを入力しますtail -f data_log | grep keyword。しかし、当時は解決されませんでした。そのため、後で使用できるようにこのtmuxセッションを維持することを決定し、ターミナルウィンドウを閉じました。
今日、私の同僚は、私のtmuxセッションにtail -f data_log | grep keywordそのログサーバーのハードドライブが不足していると言いました。これにより、私は恥ずかしさと後悔、混乱を感じました。
asはtail -f独自のstdoutファイル記述子を開き、新しく追加されたdata_logの内容を端末画面にリダイレクトします。
この標準出力ファイル記述子は無制限のデータを受け取ることができますか？
このファイル記述子はそんなに大量のデータをどこに保存しますか？保存する実際のファイルはありますか？
tmuxはこの問題に関連していますか？
tmuxがこの質問に関連していない場合は、実行中の端末を開き、tail -f my_logcrontabを使用してmy_logに1秒あたり1バイトを追加すると、1秒あたり2バイトがマイディスクに保存されます。 （tailの場合1、crontabジョブの場合1）？
ベストアンサー1
可能:
data_log毎日大量のデータが記録されます。- おそらくを使用して回転します
logrotate。一般的な回転ステップには、少なくともファイル名の変更と、圧縮されていないログの圧縮と削除が含まれます。 tail -f（少なくともGNU、その他）は、デフォルトで古いファイルが移動または削除されても、読み続けます。ファイルが削除されたがプログラムに開かれたファイルハンドルがある場合、Linuxはデータをディスクに保持し、空き容量がないとマークします。- つまり、ログの回転によってディスク容量が増えませんが、ログは圧縮されて圧縮されませんが、削除されたログが発生します。両方スペースを占めます。
この操作を十分に長く実行すると、ログの回転や他の人がログを手動で削除しようとしたにもかかわらず、サーバースペースが不足する可能性があります。