disownしたプロセスの標準出力や標準エラーを後から保存する

前の記事で、disownの素晴らしさを紹介したが、基本的に標準出力・標準エラーを諦めることになる。

調子の悪いHDDの丸ごとコピーとかだと、標準エラーを後で見たいので、なんとかならないかネット検索したところ、

gdbで接続して、dup2で標準出力・標準エラーをファイルに繋ぐなんて荒業を紹介している人がいた。

dup2なんてCプログラマじゃなきゃ使おうとも思わんな。

流れとしては、

 

  • 特定のコマンドをdisownする。前の記事参照。
  • プロセスIDを調べる
  • 標準出力、標準エラーのファイルを用意する
  • gdb -p で接続する
  • dup2でファイルに接続する。
  • デタッチ
  • gdbを抜ける

 

うーん。絶対忘れる。

 

以下、サンプル。実際はcpとかでやると思うが今回は、標準出力と標準エラーが分かりやすいようにしている。

標準出力にはdateの結果、標準エラーにはerrorを5秒間隔で。

うーん。非常にメンドイ。なるべくnohupを使いましょう。それか日常的にscreenを使いましょうってことですね。

ただ、考え方は非常に面白いので、覚えておくのはいいと思う。

readelfなんて使ったことないし、バイナリに弱すぎ

C言語を挫折した人間なので、バイナリとかアセンブラとかは全く分からない。

スクリプト言語サイコーなのだが、どうしたってサーバを動かしていれば

C言語で書かれた、デーモンやら何やらでトラブルは起きる。

先日もデーモンプログラムで、どうも変な挙動をしていたのだが

古いプログラムで、しかもソースから入れていることもあって

なんとか自力で原因究明しなくてはならなくなった。

元々、デバッグ情報付きでコンパイルされてなく

オプションを付けてコンパイルしなくてはならなかったのだが

付けたはずのオプションが、どっかで無効になったのか

gdbで実行すると、デバッグ情報が無いよ! と怒られまくった。

デバッグ情報が付かなかったのは、Makefile内の修正箇所ミスだったのだが

都度gdbを実行してから怒られており、もっと簡単に知る方法はないのかと調査した。

  • 結果

だそうです。

  • 試しにやってみた

.debug_infoというセクションが有ると、デバッグ情報付きです。

とあるapacheはデバッグ情報付きでした。

ubuntu 12.04 amd64にパッケージで入れたfirefoxは.debug_infoというセクションはありません。

.gnu_debuglink があやしい気がしますが詳細は調べてません。