2014年11月11日

第8回「カーネルパラメーターチューニングノススメ」が掲載されました。

今回はカーネルパラメータチューニングです。

予期せぬ再起動や系切り替えが発生する前に何とかして手がかりを得ようと試行錯誤を続けた結果として「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」という資料ができました。そして、その後も試行錯誤を続けた結果、今度は SystemTap が役に立つかもしれないということに気が付きました。

# stap -g -e '
function call_panic() %{ panic("Calling panic() due to machine restart\n"); %}
probe kernel.function("machine_emergency_restart") { call_panic(); }
probe kernel.function("machine_restart") { call_panic(); }' &

SystemTap を用いて行っていることは簡単で、 /sbin/reboot -f であろうと Watchdog のタイムアウトであろうと echo b > /proc/sysrq-trigger であろうと、システムを再起動するための関数呼び出しが発生したらカーネルパニックを発生させます。カーネルパニックを発生させることができれば、 kdump を取得して解析することができる筈ですから。
ただし、残念ながらトリプルフォールトのように SystemTap を仕掛けられないケースもあります。また、熊猫自身は問題事象の発生する環境を持ち合わせていないため、どれくらい効果があるのかは不明です。

posted by 熊猫さくら at 20:48| Comment(0) | TrackBack(0) | Linux

2014年10月28日

第7回「 sosreport ノススメ」が掲載されました。

今回は sosreport の紹介です。主に、システム構成の把握/ログの確認/リソース使用状況の確認のために取得していただいている訳ですが、いろいろと落とし穴があります。勝手にカーネルモジュールをロードしてしまうとか、大量のCPU時間を消費したりとかディスクI/Oを発生させたりとかの話は本文を参照していただくとして、ここでは調査担当者としての苦労話を書こうかと思います。

リソース使用状況の取得に sysstat ではなく商用の運用監視ツールを使っているために、計算式がどうなっているのかとかグラフをどう見ればよいのかとかが不明というケースがあります。サポート対象外の製品については OSS センタから当該製品のサポート窓口に照会する術を持ち合わせていないため、ログやリソース使用状況の確認ができませんので、お客様のほうから当該製品のサポート窓口に照会していただくことになります。

そうそう、計算式といえば、回収可能なメモリを加味した空きメモリの計算方法というのは長年の課題なんですよね。 RHEL 6.6 カーネルの /proc/meminfo には RHEL 7.0 カーネルに存在している MemAvailable: という項目がバックポートされており、 /proc/sys/vm/meminfo_legacy_layout に 0 を書き込むことで表示されるようになります。この項目があると、空きメモリの監視が格段に楽になるのではないかと思います。

で、話を元に戻しますと、他には、 sysstat を使っているけれども、取得したデータがすぐにログサーバに移動されてしまうために /var/log/sa/ 配下には保存されておらず、せっかく sosreport を取得していただいたのに、リソース使用状況を確認できないというケースもあります。しかし、 sosreport の取得をお願いする時点では、 sysstat の使用有無やログの保存場所がどこに設定されているのかは不明な訳です。そして、お客様のサーバにログインして構成を調査をすることはできませんので、お客様のサーバ向けにカスタマイズしたログの取得手順を提示することもできない訳です。

ですので、今回の記事を読んで、ログファイルがどこに保存されているかをトラブルに遭遇する前に把握して、 sosreport には含まれていない必要なログファイルを一緒に取得していただけると有難いなぁと思っている訳です。

え?ログファイルがどこに保存されているかを知るためのツールは無いのかって?

それなら、緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」で紹介した TOMOYO や AKARI の出番ですね。

posted by 熊猫さくら at 21:12| Comment(0) | TrackBack(0) | Linux

2014年10月14日

第6回「 Bugzilla ノススメ」が掲載されました。

今回は Bugzilla の紹介です。ここでは、「再現手順を確立することの重要さ」の例として、熊猫が先月対応していた不具合事例について紹介したいと思います。

この不具合は以下のような経緯により原因が特定され、修正されました。現在は RHEL 6/7 カーネルにバックポートされるのを待っている状態です。

  1. Red Hat 社がカーネルパニック発生時点での解析結果と矛盾点を公開( https://access.redhat.com/solutions/640843 )していた。
  2. お客様は原因不明のカーネルパニックに悩まされており、( HP 社サーバと一緒に購入した OEM 版の RHEL サブスクリプションを使用していたため)サポート窓口となる HP 社に照会を行い、上記の不具合情報の存在について把握した。
  3. お客様は NTT OSS センタにも照会を行い、再現手順を確立できないと先に進めないことを理解した。そして、お客様自身が cgroup を使用していると発生頻度が高くなることを突き止め、問題事象を再現できる手順を確立した。
  4. OSS センタでは、上記の矛盾点が発生しそうな箇所で整合性検査を行う SystemTap スクリプトを作成し、 SystemTap を用いた調査を提案した。
  5. お客様は SystemTap を用いた情報取得を行い、カーネルパニックに至るシグナルを受信するよりも前に矛盾点が発生していることを突きとめることができた。
  6. SystemTap で取得した情報を基に OSS センタで解析し、 cgroup に含まれるスレッドセーフでは無い処理が問題事象の発生原因であることを突きとめることができた。
  7. コミュニティに報告し、問題が修正( https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2ad654bc5e2b211e92f66da1d819e47d79a866f0 )された。

この不具合は5年前に公開された Linux 2.6.31 で混入し、不整合状態の発生条件が命令の実行タイミングに強く依存していたことと、不整合状態が発生してからシグナルを受信するまでの処理の流れを kdump の情報から追うことができないケースという特殊さが組み合わさって、不明瞭なカーネルパニックを引き起こしてきたようです。問題事象が発生する環境と同一のハードウェアやシステム構成を持ち合わせていない OSS センタでも問題事象を再現させることができず、お客様自身が問題事象の再現手順を確立する以外に先に進めないという状況にありました。そして、関係各位の連携プレーにより、見事解決することができました。

問題解決までの流れを知っておくと、サポートを利用する側としてどのようなことができるかを考えることができるようになります。スムーズな問題解決のために、ご協力をお願いいたします。

posted by 熊猫さくら at 20:13| Comment(0) | TrackBack(0) | Linux

2014年10月01日

bash 脆弱性( CVE-2014-6271 )の回避策として LD_PRELOAD 環境変数を使うことの罠について

サポートケースに投げても customerservice 宛に投げても secalert 宛に投げても反応が無いので、ここで説明することにします。( 10/2 追記: secalert の中の人から反応がありました。スパムキューの中に埋もれていて気付いていなかったそうです。 10/7 追記: PassEnv LD_PRELOAD を追加するように記述が修正されました。)

https://access.redhat.com/articles/1212303 には、「 /lib/bash_ld_preload.so による回避策は潜在的に危険であるため、(システム全体に適用されてしまう) /etc/ld.so.preload にではなく(サービス単位での適用が可能な) init スクリプトでの LD_PRELOAD 環境変数の設定を推奨する」という記述があり、一例として httpd サービスに適用する手順が紹介されています。

If you wish to apply this workaround across the entire system:

  • Add the following to /etc/ld.so.preload on a line by itself:
/lib/bash_ld_preload.so
  • Restart all relevant services or reboot the system.

Note that this is potentially very dangerous. It is recommend that you just apply this workaround to specific services that may be exploitable on your system. This can be achieved by adding bash_ld_preload.so to the LD_PRELOAD environment variable in the script that will initialize the service. For example, for httpd on Red Hat Enterprise Linux 6:

  • Add the following two lines at the top of /etc/init.d/httpd, after the shebang line:
LD_PRELOAD=/lib/bash_ld_preload.so
export LD_PRELOAD
  • Then restart httpd:
# service httpd restart

しかし、上記のように LD_PRELOAD 環境変数を設定しても、効果はありません。効果が無いことを確認する手順を以下に説明します。

C言語で作成されたCGIプログラムを使って確かめてみましょう。

---------- Source code of /var/www/cgi-bin/test.cgi start ----------
#include <stdio.h>

int main(int argc, char *argv[], char *environ[]) {
  int i;
  printf("Status: 200\r\n");
  printf("Content-type: text/plain\r\n");
  printf("\r\n");
  for (i = 0; environ[i]; i++)
    printf("%s\n", environ[i]);
  return 0;
}
---------- Source code of /var/www/cgi-bin/test.cgi end ----------

このCGIを叩いてみましょう。

# curl -H 'User-agent: foobar' http://127.0.0.1/cgi-bin/test.cgi

HTTP_USER_AGENT=foobar という行は表示されるのに対して、 LD_PRELOAD=/lib/bash_ld_preload.so という行は表示されないことが確認できます。言い換えると、 LD_PRELOAD 環境変数は /usr/sbin/httpd プロセスには継承されていますが、 /usr/sbin/httpd プロセスから起動されるCGIプログラムには継承されていないことを意味しています。

そのため、 /etc/init.d/httpd の中で LD_PRELOAD 環境変数を設定する方法では、 以下のように /bin/bash を呼び出す可能性のあるCGIプログラムを保護することはできません。

---------- Content of /var/www/cgi-bin/test1.cgi start ----------
#!/bin/sh
echo "Status: 200"
echo "Content-type: text/plain"
echo ""
exec /bin/env
---------- Content of /var/www/cgi-bin/test1.cgi end ----------
---------- Source code of /var/www/cgi-bin/test2.cgi start ----------
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  printf("Status: 200\r\n");
  printf("Content-type: text/plain\r\n");
  printf("\r\n");
  fflush(stdout);
  system("/bin/env");
  return 0;
}
---------- Source code of /var/www/cgi-bin/test2.cgi end ----------

以下のような叩き方をすれば、 /tmp/file を作成できてしまう訳です。

# curl -H 'User-agent: () { :;}; exec /bin/touch /tmp/file' http://127.0.0.1/cgi-bin/test1.cgi
# curl -H 'User-agent: () { :;}; exec /bin/touch /tmp/file' http://127.0.0.1/cgi-bin/test2.cgi

環境変数が意図した範囲に継承されているかどうかを理解しないまま、 LD_PRELOAD 環境変数による回避策を使おうとするのは危険です。

posted by 熊猫さくら at 21:59| Comment(0) | TrackBack(0) | Linux

2014年09月30日

緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」が掲載されました。

デング熱で騒いでいたと思った世の中が、突然 bash 脆弱性とか御嶽山噴火とかで騒ぎ出しました。今回の bash 脆弱性は、まさに TOMOYO とか AKARI とか CaitSith とかが活躍するケースな訳ですが、 Red Hat 社のサポート対象外な機能であるため、商用サポートを必要とするお客様に紹介することができず、焦りと残念さが募っています。

でも、せっかく連載をしているところですので、思い切って緊急コラムとして掲載しちゃいました。(即日で作成したので詳細までは準備できませんでした。質問などがありましたら遠慮なくどうぞ。)

熊猫がセキュリティキャンプに参加するようになってから今年で4回目になる訳ですが、年々技術的なトピックから離れてきているのを感じています。それは、OSレベルのアクセス制御に興味を持ってくれる人が少ないからという理由もあります。しかし、「プログラムのアイデア出しから保守まで全部を自分で行う」側から「他人が作成したプログラムの不具合調査を行う」側になったことで、「誰かが面倒を見てくれている筈だから、自分は考えなくてよい」という「隅々から全体までを通して見ようとしない」姿勢こそが問題の根底にあるのではないかと思うようになったからという理由もあります。なので、今年のキャンプでは、熊猫が感じている現在のSI業界の問題点を取り上げ、

「自分に関係しないことは気にしない」では済まされない。
システムのトラブル/セキュリティの脅威は、助け合いなしでは対処できない。

という話を含めました。あまりに dis りすぎたため、公開したら怒られそうな内容になってしまいましたが、まさに今回の脆弱性のような「事件」への対応姿勢がそれを問うているように思えます。

posted by 熊猫さくら at 21:29| Comment(0) | TrackBack(0) | Linux

第5回「 SysRq ノススメ」が掲載されました。

今回は SysRq の紹介です。

全プロセスのバックトレースを取得する方法として SysRq-t と kdump とがあり、 SysRq-t には以下のような利点があります。

  • 動作中のマシンをクラッシュさせることなく情報を取得できる
  • 時間経過に伴い処理が先に進んでいるかどうか(バックトレース内容が変化しているかどうか)を確認できる
  • それに対して、 kdump には以下のような利点があります。

  • バックトレース内にゴミが混入しないので内容を把握しやすい
  • (時間経過を伴わないため)一貫性のある結果が得られる
  • バックトレース以外にも様々な状態を確認できる
  • そのため、より確実な情報取得のためにマシンをクラッシュさせることが許されるのであれば、何回か SysRq-t を実行した後に、 SysRq-c を実行して kdump を取得するというのが好ましいと考えます。

    ちなみに、 libvirt 経由で KVM ゲストを稼働させている場合、 virsh dump コマンドを実行することで「動作中のマシンをクラッシュさせることなく kdump 相当の情報を取得できる」ので、 SysRq-t と kdump の両方の利点を得ることができます。 KVM ホストへのシェルログインを許可していないクラウドサービスでも、故障解析情報取得用に Web CGI インタフェースを使って virsh dump 機能を提供してもらえないものかなぁ?

    posted by 熊猫さくら at 21:27| Comment(0) | TrackBack(0) | Linux

    2014年09月16日

    第4回「 udplogger ノススメ」が掲載されました。

    今回は udplogger の紹介です。前回紹介した netconsole の受信側プログラムとしてはもちろんのこと、情報取得のために仕掛けた SystemTap の出力メッセージを受信させたり、ローカルディスクへの書き込みが遅延する恐れがある場合に数秒間隔で取得している性能データを他のホスト上に保存させたりするという使い方もできます。

    「ローカルディスクへの書き込みが遅れるなんてことあるんかいな?」と思われるかもしれませんが、実際に遅延した事例があります。 rsyslog のデフォルト設定では書き込みの完了を待つようになっているため、 Serial ATA の Native Command Queuing 機能により、業務アプリケーションによる大量のディスク I/O が優先されてしまい、死活監視で使っている /bin/su を実行した際の /var/log/secure への記録が大幅に遅延して、死活監視のタイムアウトエラーが発生してしまいました。結局、 /var/log/secure への書き込みの完了を待たないように rsyslog の設定を変更して対処しました。

    「ヤマノススメ」は風景描写が丁寧ですねぇ。「ARIA」を思い出します。 そういえば、アニメで口笛シーンが登場するのは珍しいことかも。

    posted by 熊猫さくら at 23:14| Comment(0) | TrackBack(0) | Linux

    2014年09月02日

    第3回「 netconsole ノススメ」が掲載されました。

    今回は netconsole の紹介です。 VMware や KVM などの仮想化環境の普及に伴い、ホスト側でのハードウェア増設/設定の変更/ログファイルへのアクセスが不可能という制約を持つ環境が増えてきたので、 netconsole が活躍してくれることを期待しています。

    しかし、 netconsole で難しいのは、送信側よりも受信側なのかもしれません。というのも、 netconsole のメッセージを受信しようと真面目に考えられた RHEL 同梱の(言い換えると Red Hat 社のサポート対象である)パッケージが見当たらない( https://access.redhat.com/solutions/4258 では rsyslog を紹介しているものの、 https://bugzilla.redhat.com/show_bug.cgi?id=432160 にあるようにそのままでは使い物にならない。 https://openvz.org/Remote_console_setup#Netconsole にあるように %rawmsg% を使えばとりあえず受信はできるものの、送信元やタイムスタンプの情報も一緒に記録してくれないと不便。かといって、 %fromhost-ip% と %timegenerated% と %rawmsg% とを同時に指定すると、必要以上にログファイルを肥大化させてしまうし、余分な送信元やタイムスタンプを除去してからでないと読めないというのも面倒。)ので、 udplogger を作成しました。それでも、どうしても rsyslog を使わなければいけないのであれば、 $EscapeControlCharactersOnReceive や $DropTrailingLFOnReception という指定が通常の syslog メッセージに干渉するのを防ぐために、 netconsole 専用の rsyslogd インスタンスを起動した方が良いと思います。その際、 -x オプションを忘れると、 netconsole から送信されたカーネルメッセージに含まれている文字列をホスト名だと勘違いして手当たり次第DNS問合せをしてしまいますのでご注意を。

    ♪なつい〜ろ〜プ〜レゼント〜」に「なんのこっちゃ?」と思った方へ:この連載の各話のタイトルは「ヤマノススメ セカンドシーズン」という現在放送中のアニメに倣っています。そして、「夏色プレゼント」というのは、そのアニメのオープニング曲です。前回の記事で「侵略!イカ娘」じゃないよと熊猫が書いたことに対して正解を示唆してくれているものと思われます。

    今年もセキュリティキャンプ2014が開催された訳ですが、2014年度の第1Qには「ふんわり」系のアニメがたくさん放送されていたのを反映してか、いろいろなアニメネタが登場しました。「ごちうさ」の「ぴょんぴょん」とか(由来は知らないけれど)「ておくれポイント」とかが健闘しましたが、最も猛威を振るったのは「進捗どうですか?」かと思われます。流行はしなかったけれども大爆笑したのは、「一週間フレンズ。」を捩った「進捗フレンズ。」ですねぇ。

    2014年度の第2Qは、あまり「ふんわり」系のアニメが見当たらず、ちょっと寂しいです。そんな中、「ヤマノススメ」はゆるふわキャラクターによる山登りの話だと思っていたのに、なぜか温泉の話、スカートの話、水着の話と山じゃない話が続いていてドキドキ。(笑)いや、ゆるふわでも真面目なアニメなので問題描写は登場しない筈。

    posted by 熊猫さくら at 21:36| Comment(0) | TrackBack(0) | Linux

    2014年08月19日

    第2話「シリアルコンソールノススメ」が掲載されました。

    kdump を設定済みのサーバは増えてきたようですが、シリアルコンソールを設定したサーバはまだ多くはないようです。同一のサーバで複数回の予期せぬリブートを経験して初めてシリアルコンソールの設定を検討するようになるという状況ですので、予期せぬリブートの原因についての問合せでは初回の事象発生時に何も手掛かりを見つけられず、残念な思いをすることが多いです。しかも、再発するまでに何ヶ月も待たされることが多く、調査する側としては何だか落ち着かない状況が続きます。この記事が、初回発生時に手掛かりを見つけるのに役に立てばいいなぁ。

    誰かさんは
    > 現在放送中の某アニメに倣って「○○ノススメ」を予定しています。
    という部分を読んで何のアニメなのかを検索したらしく、「侵略!イカ娘」ですかと訊かれてしまいました。
    え〜?そっちは知らないにゃ〜。(笑)

    posted by 熊猫さくら at 22:21| Comment(0) | TrackBack(0) | Linux

    2014年08月05日

    不定期連載「OSSコラム 安らかな夜を迎えるために」を始めました。

    LinuxCon Japan 2014 で使用した「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を、紙面では説明しきれなかった内容も含めて丁寧に解説することにより、業務用 Linux サーバ管理者のトラブルシューティングスキル向上に資することを願って、「OSSコラム 安らかな夜を迎えるために」を開始しました。

    本業にいつ余裕ができるかを全く予測できないという性質上、原稿を書く時間を定期的に割けることを約束できないため、不定期連載という形になります。各話のタイトルは、現在放送中の某アニメに倣って「○○ノススメ」を予定しています。

    posted by 熊猫さくら at 21:06| Comment(0) | TrackBack(0) | Linux

    2014年05月16日

    「セキュリティ・キャンプ全国大会2014」参加者募集が始まりました。

    撮影されないようにカメラから逃げ回っている熊猫が、何故かクラス紹介の動画で喋るはめになってしまいました。(汗)

    昨年度は「セキュリティの見える化を考えるゼミ」という名前で募集し、「利用者を置いてけぼりにしないセキュリティを考えてみよう」というテーマには8名もの応募がありました。セキュリティについて利用者が置いてけぼりにされているというモヤモヤ感を持った人が予想以上に多く存在していると感じました。そして、セキュリティという得体のしれないものを相手にするのは学生には難しいとも感じました。

    そのため、今年はOSのセキュリティを考える前段階である「OSの見える化を考えるゼミ」という名前で募集します。応募者の希望テーマに応じて講義内容を考える予定ですが、参考資料として、来週 LinuxCon Japan 2014 の発表で使用する「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を紹介しておきます。

    posted by 熊猫さくら at 23:55| Comment(0) | TrackBack(0) | Linux

    2014年03月10日

    netconsole メッセージ受信用プログラムを作りました。

    仕事として Linux サーバのトラブル対応をしているのですが、障害発生時のカーネルメッセージは /var/log/messages に残せないため、 /var/log/messages を確認しても原因が判らないものです。技術的にはカーネルメッセージをシリアルコンソールに出力することができるのですが、運用としてシリアルコンソールを導入することが困難なサーバが多く、もどかしい思いをしていました。

    そんな中、 netconsole をシリアルコンソールの代替機能として活用できそうだと判明したので、 netconsole からのメッセージを受信するための専用プログラムを作成して http://sourceforge.jp/projects/akari/scm/svn/tree/head/branches/udplogger/ に置きました。

    コメントおよびディストリビューション向けパッケージのメンテナになっていただける方を募集しています。

    posted by 熊猫さくら at 21:44| Comment(0) | TrackBack(0) | Linux

    2013年12月21日

    208.5 日問題の逆襲

    昨年の始め頃、 208.5 日以上連続稼働すると動作が停止したり kernel panic が発生したりする可能性があるという TSC 絡みの不具合が話題になりました。

    Linux カーネルの sched_clock() が 208.5 日の連続稼働でオーバーフローする現象について
    https://access.redhat.com/site/solutions/121233

    Does Red Hat Enterprise Linux 6 or 5 have a reboot problem which is caused by sched_clock() overflow around 208.5 days?
    https://access.redhat.com/site/solutions/68466

    しかし、上記の不具合を修正したカーネルには落とし穴があったようです。(誰も話題にしないので、注意喚起の意味で URL を貼っておきます。)

    Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
    https://access.redhat.com/site/solutions/433883

    手元の VMware Player 上で 4 VCPU を割り当てた CentOS 6 32bit 環境において、 TSC の書き換えにより連続稼働をエミュレートするという方法で再現試験を行った限りでは、この不具合の再現率は100%のように見受けられます。

    Intel Xeon E5 は業務用サーバとして広く使われていると思いますので、油断していると襲われますよ〜。

    posted by 熊猫さくら at 23:51| Comment(6) | TrackBack(0) | Linux

    2012年11月11日

    Linux Security Modules に変化の兆しが出てきました。

    いろいろと Linux 利用者を悩ませてきたLSMですが、変化の時が近づきつつあるようです。

    熊猫の9年間の試行錯誤を纏めて LinuxCon North America と Linux Security Summit で発表した、 ARIA ワールド満開(嘘)なプレゼン資料も貼っておきます。アクセス制御に興味のある方に読んでほしいなぁ。

    posted by 熊猫さくら at 19:47| Comment(0) | TrackBack(0) | Linux

    2012年05月30日

    Fedora 17 ネットワークインストール時の注意点

    Fedora 17 のネットワークインストーラは、環境によっては「次へ」ボタンが表示されないことがあるようです。以下は熊猫の PC 上の VMware Workstation 上に Fedora-17-i386-netinst.iso からインストールしようとした時の画面です。
    fedora17-net-installer.png
    画面外には表示されているので、 Tab キーを使ってフォーカスを移動してください。

    以下は同じ条件で Fedora-17-i686-Live-Desktop.iso からインストールしようとした時の画面です。
    fedora17-live-installer.png

    どうしても最小インストールをしたいと言うのでなければ、 Live 版を使う方が正解かと思います。

    https://bugzilla.redhat.com/show_bug.cgi?id=826351

    posted by 熊猫さくら at 21:19| Comment(0) | TrackBack(0) | Linux

    2012年05月18日

    DRBD モジュールが突然動かなくなったときにチェックすること

    Linux 3.4 では、 call_usermodehelper() の引数で指定されている UMH_* 定数の値が変更されています。 UMH_* 定数の代わりにハードコードされた整数を指定しているソースコードは、 Linux 3.4 以降では期待通りに動かなくなります。

    現時点では、この修正は Ubuntu にバックポートされています。この修正は他のいくつかのディストリビューションにもバックポートされることが予想されます。
    call_usermodehelper() を含むコードを使用する場合、 UMH_* 定数を使用するように修正されているかどうか確認するようにしてください。

    一例として、 DRBD モジュールでは call_usermodehelper() でハードコードされた整数を指定していたため、バグ報告が出ています。
    https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1000355

    posted by 熊猫さくら at 21:32| Comment(0) | TrackBack(0) | Linux

    2012年05月13日

    Thunderbird でメールが突然消えたときにチェックすること

    Linux にあまり関係ない話ですが、 Windows 版だけでなく Linux 版でも再現できるバグだったので、ここに載せておきます。

    Thunderbird で受信したメールを整理しようとしてフォルダを作成していた時に、 Thunderbird では受信したメールを保存するフォルダの名前が「受信トレイ」と表示されていたので、「それなら Inbox という名前のフォルダを作成しても大丈夫だろう。もし駄目ならエラーメッセージが表示されて作成できないようになっているだろうから。」と思って、 Inbox というフォルダ名を指定したところ、既に存在する Inbox フォルダの内容が消滅してしまうという恐ろしいバグを踏んでしまいました。(証拠動画: http://www.youtube.com/watch?v=No3lyZNk9Hc

    https://bugzilla.mozilla.org/show_bug.cgi?id=749909 にて進行中ですが、その中にナレッジベースへのリンクが登場したので、貼っておきます。

    http://kb.mozillazine.org/Disappearing_mail

    こういう情報は事前に知っておかないと間に合わないでしょうから・・・今回のバグには無力そうな気がしますが・・・。

    posted by 熊猫さくら at 20:11| Comment(0) | TrackBack(0) | Linux

    2012年05月02日

    tail -f が機能しない時にチェックすること

    近頃のディストリビューションで採用されているバージョンの tail コマンドは inotify を使っているため、環境によっては tail -f が希望通りに機能しないことがあるようです。 Ubuntu 12.04 の LiveCD から tail -f を試してみたのですが、動きませんでした。

    # tail -f /var/log/tomoyo/reject_000.txt /var/log/tomoyo/reject_001.txt /var/log/tomoyo/reject_002.txt /var/log/tomoyo/reject_003.txt

    strace で確認すると、特定のファイルディスクリプタの読み込みでブロックしていることが判ります。

    # strace -p `pidof tail`
    Process 4418 attached - interrupt to quit
    read(7,^C <unfinished ...>
    Process 4418 detached

    ls で確認すると、そのファイルとは anon_inode:inotify であることが判ります。

    # ls -l /proc/`pidof tail`/fd/
    total 0
    lrwx------ 1 root root 64 May 2 11:40 0 -> /dev/pts/0
    lrwx------ 1 root root 64 May 2 11:40 1 -> /dev/pts/0
    lrwx------ 1 root root 64 May 2 11:40 2 -> /dev/pts/0
    lr-x------ 1 root root 64 May 2 11:40 3 -> /var/log/tomoyo/reject_000.log
    lr-x------ 1 root root 64 May 2 11:40 4 -> /var/log/tomoyo/reject_001.log
    lr-x------ 1 root root 64 May 2 11:40 5 -> /var/log/tomoyo/reject_002.log
    lr-x------ 1 root root 64 May 2 11:41 6 -> /var/log/tomoyo/reject_003.log
    lr-x------ 1 root root 64 May 2 11:41 7 -> anon_inode:inotify

    inotify を使わせないようにするには、 ---disable-inotify という隠しオプションを使います。 - が3つ連続していることに注意してください。

    # tail ---disable-inotify -f /var/log/tomoyo/reject_000.txt /var/log/tomoyo/reject_001.txt /var/log/tomoyo/reject_002.txt /var/log/tomoyo/reject_003.txt

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583198

    posted by 熊猫さくら at 21:20| Comment(0) | TrackBack(0) | Linux

    2012年04月22日

    メモ: EOL した CentOS 4 用の yum 設定

    CentOS 4 は EOL を迎えたわけですが、既にミラーサーバ上から消滅しているので、 yum 設定の更新が必要です。

    # yum -y update
    Setting up Update Process
    Setting up repositories
    not using ftp, http[s], or file for repos, skipping - 4 is not a valid release or hasnt been released yet
    Cannot find a valid baseurl for repo: update
    Error: Cannot find a valid baseurl for repo: update

    具体的には、 baseurl 行にサーバとして vault.centos.org を指定します。

    # sed -i -e 's/^mirrorlist=/#mirrorlist=/' -e 's/^#baseurl=/baseurl=/' -e 's@mirror.centos.org/centos@vault.centos.org@' -e 's/$releasever/4.9/' -- /etc/yum.repos.d/CentOS-Base.repo
    posted by 熊猫さくら at 15:57| Comment(0) | TrackBack(0) | Linux

    2012年04月17日

    ベンチマーク測定に Debian/Ubuntu の lmbench/3.0-a9-1 を使用する場合の注意点

    最初の報告から1ヶ月経ったけどまだ何の反応も無いので、犠牲者をこれ以上増やさないようにするために、先に周知します。

    lmbench パッケージには、プログラム実行に要する遅延時間を測定する lat_proc というプログラムが入っていますが、 Debian/Ubuntu の lmbench-3.0-a9 をパッケージでインストールした場合には正しい結果が得られません。

    これは、存在しない /var/tmp/lmbench/hello というプログラムを lat_proc が実行しようとするため、 execve() が失敗してしまうことが原因です。(失敗してもエラーメッセージ1つ出さないという作りはどうかと思いますが。(汗))

    TOMOYO で解析すると、 sh -c を実行しているのに hello プログラムのためのドメインが作成されていないことが確認できます。

       43:  0     /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmbench
       44:  0         /bin/cp
       45:  0         /bin/date
       46:  0         /bin/hostname
       47:  0         /bin/mkdir
       48:  0         /bin/mount
       49:  0         /bin/netstat
       50:  0         /bin/rm
       51:  0         /bin/sleep
       52:  0         /bin/sync
       53:  0         /bin/tar
       54:  0         /bin/uname
       55:  0         /sbin/ifconfig
       56:  0         /usr/bin/awk
       57:  0         /usr/bin/expr
       58:  0         /usr/bin/touch
       59:  0         /usr/bin/uptime
       60:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_file_rd
       61:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_mem
       62:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_mmap_rd
       63:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_pipe
       64:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_tcp
       65:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_unix
       66:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_connect
       67:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_ctx
       68:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_fs
       69:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_http
       70:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_mmap
       71:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_pagefault
       72:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_pipe
       73:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_proc
       74:  0             /bin/sh
                              *** ↑ hello プログラムのドメインが存在しない ***
       75:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_rpc
       76:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_select
       77:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_sig
       78:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_syscall
       79:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_tcp
       80:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_udp
       81:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_unix
       82:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmdd
       83:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmhttp
       84:  0         /usr/lib/lmbench/bin/i686-pc-linux-gnu/msleep
       85:  0         /usr/lib/lmbench/scripts/os
    

    lmbench-3.0-a9.tgz から作成すると正しい結果が得られていることが判ります。

      182:  0     /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmbench
      183:  0         /bin/cp
      184:  0         /bin/date
      185:  0         /bin/hostname
      186:  0         /bin/mkdir
      187:  0         /bin/mount
      188:  0         /bin/netstat
      189:  0         /bin/rm
      190:  0         /bin/sleep
      191:  0         /bin/sync
      192:  0         /bin/tar
      193:  0         /bin/uname
      194:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_file_rd
      195:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_mem
      196:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_mmap_rd
      197:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_pipe
      198:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_tcp
      199:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_unix
      200:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_connect
      201:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_ctx
      202:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_fs
      203:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_http
      204:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_mmap
      205:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_pagefault
      206:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_pipe
      207:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_proc
      208:  0             /bin/sh
      209:  0                 /tmp/hello
                              *** ↑ hello プログラムのドメインが作られている ***
      210:  0             /tmp/hello
      211:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_rpc
      212:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_select
      213:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_sig
      214:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_syscall
      215:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_tcp
      216:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_udp
      217:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_unix
      218:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmdd
      219:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmhttp
      220:  0         /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/msleep
      221:  0         /sbin/ifconfig
      222:  0         /usr/bin/awk
      223:  0         /usr/bin/expr
      224:  0         /usr/bin/touch
      225:  0         /usr/bin/uptime
    

    ということで、 lmbench/3.0-a9-1 を使う場合、事前に hello プログラムを /var/tmp/lmbench/hello にコピーするか、あるいは、 lmbench-3.0-a9.tgz からコンパイルしたものを使用するようにしてください。(これ以外にも不具合があるかもしれないので、修正が完了するまでは lmbench-3.0-a9.tgz からコンパイルする方がおススメです。)

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666072

    posted by 熊猫さくら at 20:29| Comment(0) | TrackBack(0) | Linux