非常に長く実行され、大量の出力を生成するバッチシステムのジョブがあります。実際には、バッチノードが作業領域を埋め尽くしてクラッシュするのを防ぐために、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を説得するにはどうすればよいですか?
ファイルの最後以外に、zcat
(またはgzip -dc
、またはgunzip -c
)を使用して非圧縮データを表示できます。
zcat log.gz | tail
または
zcat log.gz | less
または
zless log.gz
gzip
は明白な理由でバッファリングを行います(データをチャンクに圧縮する必要があるため)。プログラムが一部のデータを出力したとしても、そのデータはlog.gz
ファイルにまだ含まれていない場合があります。
非圧縮ログを保存することもできます
zcat log.gz > log
...しかし、最初に出力を圧縮する理由が明らかにあるので、それはばかげたことでしょう。
私が正しく理解しているなら、あなたはまだ成長しているgzipファイルでtail -f
のようなことをしたいと思います:私は gztool を開発しましたそれを行う(とりわけ):
$ gztool -T log.gz
そして、それは継続的にコンソールに出力され、必要なときに新しいデータを待ちます。
gztool
もインデックスファイル(この場合はlog.gzi
)を作成し、gztool
を使用してgzipデータへの末尾またはその他のランダムアクセスをほぼ瞬時に行うことに注意してください。インデックスを作成したくない場合は(0.3%/ gzipサイズであり、処理時間は増加しません)、-W
を使用して作成しないでください。
ファイルを分割して、それぞれをgzipすることができます: https://stackoverflow.com/a/2016918/309095
とにかく、冗長モードでコマンドを実行できますか?これにより、より多くの情報が提供されます。