アクティブなログファイルから最初のN行を削除する

Nアプリケーションによってアクティブに追加されているログから最初の行を削除する方法はありますか？

いいえ、Linuxなどのオペレーティングシステム、およびそのファイルシステムは、ファイルの先頭からデータを削除するためのプロビジョニングを行いません。つまり、ファイルのストレージの開始点は固定されています。

ファイルの先頭から行を削除するには、通常、残りのデータを新しいファイルに書き込み、古いファイルを削除します。プログラムが古いファイルを書き込み用に開いている場合、そのファイルの削除は、アプリケーションがファイルを閉じるまで延期されます。

コメント者が述べたように、私の前の文で与えられた理由のために、通常、ログを書き込むプログラムとログファイルの整理を調整する必要があります。正確にこれを行う方法は、プログラムによって異なります。いくつかのプログラムは、シグナル（HUPなど）を送信するとログファイルを閉じて再度開きます。これを使用すると、サービスを中断することなく、ログレコードが「削除された」ログファイルに書き込まれないようにできます。

logrotateなど、ログファイルのサイズを管理するための多くのユーティリティがあります。

一部のプログラムには独自のユーティリティがあります。たとえば、Apache Webサーバーにはrotatelogsユーティリティが含まれています。

このタスクは次の方法で達成できると思います sed

sed -i '1,10d' myfile

1から行削除します^STを 10に^目のファイル形式のライン。

少なくとも誰もがこのsed 1ライナーを見るべきだと思う。

これは、アプリケーションによってアクティブに追加されているログファイルでは機能しないことに注意してください（質問で述べたように）。

sed -i新しいファイルを作成し、書き込まれているファイルを「削除」します。ほとんどのアプリケーションは、削除されたログファイルにログレコードを書き込み続け、ディスクスペースを使い続けます。切り捨てられた新しいログファイルは追加されません。これは、アプリケーションが再起動されるか、ログファイルを閉じて再度開くように指示された場合にのみ停止します。sedの使用とアプリケーションの再起動の間にログ可能なアクティビティがあった場合、新しいログファイルにギャップ（ログレコードの欠落）が生じます。

これを行う安全な方法は、アプリケーションを停止し、sedを使用してログを切り捨ててから、アプリケーションを再起動することです。このアプローチは、一部のサービス（たとえば、高スループットと高いサービス継続性要件を備えたWebサーバー）では受け入れられない場合があります。

いいえ。ログファイルの増大というこの一般的な問題の解決策は、ログのローテーションです。これには、既存のログファイルを他のファイル名に定期的に（通常は毎晩または毎週）移動し、空のログファイルから新たに開始することが含まれます。しばらくすると、古いログファイルは破棄されます。

参照：http : //www-uxsup.csx.cam.ac.uk/~jw35/courses/apache/html/x1670.htm

これは答えであり、解決策ではありません。質問に対する解決策はありません。質問者は「アプリケーションによってアクティブに追加されているログから」と明確に述べています。続き を読んで理解を深め、最後までスキップして、このコードがロギングのベストプラクティスに従っていない理由を推測して、提案を行うことができます。

明確にするために、ここの他の「答え」は虚偽の約束を提供します。名前を変更しても、アプリケーションが新しいファイルを使用するようにだますことはありません。最も有用な情報は、これらの誤った回答に対するコメントに埋もれています。

ACTIVEファイルは、単にデータを入れるだけのコンテナではありません。ファイル名は1つのiノード（ファイルの先頭）を指し、すべてのiノードには別のiノードへのポインターがあります（さらにデータがある場合）。つまり、継続的に書き込まれるファイルには、追加されるiノードの一定のストリームがあり、「ファイル」について考えるのは、実際にはiノードのログシーケンスです。

Googleマップで誰かを追跡していて、その人がいつでも世界中のどこにでもテレポートでき、これらのドットを接続しようとしていると想像してください。

Linuxツール「truncate」は、iノードツリーを単純にたどることにより（指定した場所/サイズで）ファイル内のデータを破棄でき、スタック内の後続のポインターをすべて破棄します。ファイルの先頭でデータを破棄するという逆の操作を行うと、リアルタイムで iノードツリーを書き換えるという恐ろしく複雑で危険なプロセスになります。データロス。ウィキiノード短いですが、これらの概念のいくつかを説明します。

**私のアドバイス：この問題を回避する-なぜこのアプリケーションはこのように動作するのでしょうか？多くのロギングベストプラクティスがありますが、多くの場合、それらは実際のロギングシステム（syslogなど）に関係しています。コアでは、アプリケーションはファイルへのハンドルを「解放」することが期待されるため、logrotate（など）は古いデータのさらなる処理を処理できます。

「ACTIVEログファイルへ」と聞くたびに、すぐにその人にこのアプリケーションの背後にある「特別な物語」を教えてくれるように頼みます。通常、開発者は終了し、コードを変更できません。これは実際には安全性の逆であり、独自のリスクがあります。しかし、ソースコードに触れないようにするソリューションが必要です。ケースでは、より具体的な質問が必要です。

崇高なテキストで開くファイルが追加されている場合でも、行を削除してファイルを保存すると何らかの形で機能しますが、コマンドラインソリューションのソリューションを検索するためにここに来たので、この作業は役に立たないソリューションをここに残します!!

たぶん、コピー、切り捨て、コピーを末尾に戻してsize = 0の切り捨て、コピーを削除しますか？

テールからテールへのコピーを改善し、オリジナルを切り捨て、テールコピーをオリジナルに連結します。

ログの行の末尾の長さはバイト長の制限よりも優れています。

コメントから詳細を修正：

まず、Python3のロガースクリプトがあります。

from time import sleep

idx = 0
while 1 == 1:
    idx = (idx + 1)
    lf = open('tailTrunc.log', 'a')
    lf.write("line to file " + str(idx) + '\n')
    lf.close()
    sleep(0.01)

次に、トランケーターがあります

#!/usr/bin/env bash

trap "kill 0" EXIT

rm tailTrunc.log
touch tailTrunc.log

python3 logLoop.py &
loggerPID=$!
sleep 1

kill -STOP $loggerPID
tail -10 tailTrunc.log > trimEnd.log
truncate -s 0 tailTrunc.log
kill -CONT $loggerPID
sleep 1

trimEnd.logは80から89を示しています

ログには90から終了までが表示されます

とにかく意志があるところには方法があります。

コンソリデーターのより複雑な例と書き込みストリームのオープンまたはクローズ方法は、CPUコアごとに調整する必要がある場合があります。ロギングプロセスなどのロガーでできる場合は、書き込みを一時停止してキューに入れるだけです。