Zsh履歴が消えるバグを追跡、クラッシュで真実を暴く
Tracking down a Zsh history data loss bug
長年、Zshの履歴ファイルからコマンドが消える問題に悩まされていた著者が、inotify、fatrace、bpftraceなどのツールで原因を追跡。最終的には、Zshに意図的にクラッシュを仕込んでcore dumpを解析することで、バグの根本原因を特定しました。Zsh 5.9.2で修正済みです。
最終的に、Zshをわざとクラッシュさせて、そのcore dumpを解析することが勝利の戦略でした。
HNでの議論
38- mmh0000
私はほぼ10年分のzsh履歴を持っています。その記事を読んで、私は過去にそのバグに遭遇したかもしれないが気づかなかったという結論に達しました。
それから読み続けると、著者が誤ってHISTFILE[1]をエクスポートしたことに言及していて、私は恐怖で叫び、コンピュータに走りました。なぜなら、私はこれまでずっと同じ間違いを犯していたことに気づいたからです。
この記事を読んで、私は今、嬉しくもあり悲しくもあります。
[1] https://github.com/stapelberg/configfiles/commit/32dcda0f49a...
- pratyahava
これは、何年も前からあるツールであるファイルシステムを使えば避けられたはずの、過度に複雑な解決策の例です。なぜ、複数のセッションのコマンド履歴をすべて1つのファイルに「賢く」まとめるというこの「英雄的な」努力をするのでしょうか。各セッションのコマンド履歴をディレクトリ内の新しい別々のファイルに書き込み、1つのファイルを読む代わりにディレクトリからすべての履歴ファイルを読めばいいのに。
- chillpenguin
私は数年前にこれに遭遇しました（または非常によく似たバグに遭遇しました）。履歴を失うのがとても煩わしかったので、履歴ファイルを定期的にバックアップし始めました。バックアップは続けますが、この修正はありがたいです！
- TZubiri
zshにはデフォルトで2000コマンドの制限があるのですか？
そのようなデフォルトを持つシステムに多くを期待することはできません。私は伝統を支持しますが、コマンド履歴に依存するなら、bash_historyを読むようなものには頼りません。革命が必要であり、漸進的な最適化ではありません。
追伸：私がしているのは、サイズと行数の両方を無制限に設定することですが、それはフォレンジックグレードの監査証跡ではありません。OSやsshコマンドロガーが必要です。できれば外部ディスクに書き込むもの、少なくともrootが管理するファイルに書き込むもので、ユーザー所有のファイルには絶対に書き込まないものが必要です。
セキュリティは攻撃者からだけでなく、バグからも保護します。ユーザーのコマンド履歴はユーザーによって削除されるべきではありません。それ以外は、慣性と怠惰によって引き継がれている間違ったアーキテクチャです。
- nubinetwork
それがバグなの？bashでいつも起こるよ。2つのターミナルを同時に開くだけで...最後に閉じた方が履歴を書き込むんだ。/shrug