RHELを題材にソースが見える環境を作る

ソースコードを見ればトラブルの原因がわかる

　筆者は、顧客の環境で発生した弊社製品（Red Hat Enterprise Linux、以下RHEL）のトラブルの原因を調査する仕事に従事しています。この仕事をしていて大変に印象的なのは、「簡易なソースコード読解作業」によって多くの問題の原因を突き止めるに至っている、ということです。

　「簡易なソースコード読解作業」とは、例えば次のようなものです。今、トラブルに対応すると考えられるログ出力を得たとします。トラブルの原因を究明したいが、ログだけを見てもその意味がわかりません。ところがこのログ出力を行っているソースコード行を特定し、その行を囲うif文の条件式から、ログの意味がわかり、まさにそのログがトラブルの原因を説明していたことが判明しました。

　この程度の読解作業であれば、文字列検索コマンドの実行方法と対象となるプログラミング言語の文法を知っていれば実施できます。たとえ解決に至らなくとも、コストはそれほどかからないので、障害の原因特定には「ぜひソースコードを活用してください」とRHELをお使いのみなさまにお勧めしたいところです。

なぜ、手間と時間がかかるのか

　ところがRHELでこれを実行しようとすると手間と時間がかかります。読解作業の前提となるソースコードが簡単には閲覧できないのです。ソースコードがなければ読解のテクニックや豊富な経験を披露しようもありません。以下に、この手間と時間を具体的に説明します。この説明は、RHELに限らずFedoraなどRPM系のGNU/Linuxディストリビューションにもあてはまるはずです。

　1つ目が入手先を特定する手間とダウンロードの待ち時間です。RHELは1000個程度のバイナリパッケージの集合からなります。各バイナリパッケージに対して、src.rpmと呼ばれる形式でそのソースコードをftp.redhat.com からanonymous ftp経由で入手できます。ここでまず、目的のパッケージの目的のバージョンがftp.redhat.comのどこにあるのかを捜す手間と、ダウンロードの待ち時間が発生します。

　2つ目がsrc.rpmファイルのインストールの手間です。rpmコマンドを実行して、src.rpmファイルをファイルシステムにインストールする必要があります。

　3つ目がソースコード復元の手間です。src.rpmファイルをrpmコマンドでインストールすると、/usr/src/redhat/SOURCESに製品のバイナリとなるソースコードの原型が配置されます。原型と書いたのは、ソフトウエアの原作者が配布するファイル（オリジナルファイル）と、それを顧客に提供するにあたり弊社開発部門が加えた変更点（パッチファイル）が分離されているためです。ほとんどのsrc.rpmファイルにおいてオリジナルファイルはtar.gzなどの形式で圧縮されています。パッチファイルはその名の通りpatch形式のファイルです。

　ここで、rpmbuildコマンドを用いてソースコードを復元しなければいけません。rpmbuildコマンドは、オリジナルファイルを伸長し、そこにパッチファイルを適用してソースコードを復元します。/usr/src/redhat/BUILD/パッケージ名以下にソースコードは復元されます。

　図1は、以降に説明する「ソースコードを閲覧するための環境」を構築したとき、その魅力を同僚に説明するために書いたプレゼンテーション資料からの抜粋です。顧客から問い合わせに即答できないことがあれば、自身の名誉と好奇心から調べたくなり、やる気が最高潮の状態になるでしょう。ところが「ソースコード復元」までのちょっとした時間が、その気持ちをむしばみます。一方、ソースコードが手元にあれば、やる気十分の形で問題に取り組むことができるのです。その変化は3ページ目で紹介します。

　ここまでRHELのソースコードに基づいて話をしてきましたが、RHELに限らず業務上ソースコードを読む必要があるのであれば、高度な読解技法などについて考える前にまず「読む必要のあるソースコードは手元にありますか？」という疑問について考えてみてください。