バッチ システムで、非常に長い時間実行され、大量の出力を生成するジョブを実行しています。出力が非常に多いため、バッチ ノードが作業領域をいっぱいにしてクラッシュしないように、標準出力を gzip でパイプする必要があります。
longscript | gzip -9 > log.gz
ここで、ジョブの実行中にその出力を調べたいと思います。そのためには、次のようにします。
gunzip log.gz
これは巨大なファイル (数 GB) なので、実行に非常に時間がかかります。実行中に出力ファイルが作成されているのを確認でき、ビルド中にそれを確認することもできます。
tail log
> some-line-of-the-log-file
tail log
> some-other-line-of-the-log-file
しかし、最終的に gzip は gzip 圧縮されたファイルの終わりに到達します。ジョブはまだ実行中で、gzip はまだファイルを書き込んでいるため、適切なフッターがまだ存在せず、次のようになります。
gzip: log.gz: unexpected end of file
この後、gzip は破損した抽出データは役に立たないと判断し、抽出されたログ ファイルは削除されます。しかし、私はこれに反対です。最後の数行が乱れている場合でも、出力は依然として私にとって非常に興味深いものです。
gzip に「破損した」ファイルを保持させるにはどうしたらよいでしょうか?
答え1
ファイルの最後を除いて、zcat(またはgzip -dc、またはgunzip -c) を使用して非圧縮データを表示できます。
zcat log.gz | tail
または
zcat log.gz | less
または
zless log.gz
gzip明らかな理由によりバッファリングが行われます (データをチャンク単位で圧縮する必要があるため)。そのため、プログラムが何らかのデータを出力したとしても、そのデータはまだファイルに含まれていない可能性がありますlog.gz。
圧縮されていないログを保存することもできます
zcat log.gz > log
...しかし、そもそも出力を圧縮する理由が明らかにあるので、それはばかげています。
答え2
tail -f私の理解が正しければ、まだ成長中のgzipファイルで次のようなことをしたいのですね。gzツール次のようなことが可能です (他にもいろいろあります):
$ gztool -T log.gz
必要に応じて新しいデータを待機しながら、コンソールに継続的に出力します。
は、今後の tails または gzip データへのその他のランダム アクセスをほぼ瞬時に行うgztoolインデックス ファイル (この場合は) も作成することに注意してください。インデックスを作成したくない場合は (0.3%/gzip サイズで処理時間が増加しない場合でも)、 を使用してインデックスを作成しないようにすることができます。log.gzigztool-W
答え3
ファイルを分割してそれぞれを gzip で圧縮してみることもできます:https://stackoverflow.com/a/2016918/3090950
とにかく、コマンドを詳細モードで実行してもらえますか? これにより、より多くの情報が提供されます。