ススメ」が掲載されました。デバッグ用カーネルの紹介です。デバッグ用カーネルの紹介だけで1話持たせるのは無理があるので、過負荷試験の話も入れました。今までは「システムがダウンするくらいにまでメモリ負荷を掛けたら、いつ回復するか予測できないストール状態に陥るのは当然だ。そのような負荷を掛けたユーザのほうが悪い」と相手にされなかったのですが、実は「無限ループに陥るトドメの一撃」を喰らわせていたのはユーザ側ではなくメモリ管理機構側だったようです。後に紛れ込んだ予期せぬ挙動の変化をきっかけに、一気に動き出しました。発生したりと、全く使い物にならなくなってしまうことが確認されたため、とりあえずは元の挙動に戻されました。メンテナとの間で将来に向けてどう修正していくのかの議論の最中なのですが、熊猫が欲している「既存のカーネルにバックポート可能な修正方法」についての話が完全に置いてけぼり状態になっています。メモリ割り当て要求が原因のシステムフリーズとさよならできるようになる日が来るのはまだ遠いのかなぁ。会議があるので、そこで何らかの進展があることを期待しています。第15回「フォールトインジェクションノススメ」が掲載されました。使ってエラーを発生させるというちょっと怖いお話です。ここでは目を離した隙にカーネルの挙動が変化しているという別の方向で怖い話をしたいと思います。カーネルにバックポートされましたが、修正されたことを知るのは面倒です。いうのも、エラータのページにはセキュリティ上の不具合の修正内容についてしか言及されておらず、「その他の修正内容についてはテクニカルノートを見てね」と書かれているのに従ってテクニカルノートのページをチェックしても、今回の不具合に該当しそうな内容が見当たりません。パッケージの変更履歴の説明文をチェックするかソースコードの差分をチェックして初めて、「あ、修正されたんだな」と判るようになっていたのです。テクニカルノートには全修正内容が網羅されていると思っていると、落し穴にはまるかもしれないということですね。発動させずに諦めるという変更が適用されてしまいました。リリースされるまでにマージするというのが本来の手順なのですが、その手順をすっとばされた訳です。ファイルシステムより低いレイヤーでのメモリ割り当てがメモリ枯渇時に失敗してしまうようだと、ファイルシステムエラーが多発してしまうので困ると思うのですが。必要な個所を全て洗い出して修正してからにしてほしかったんだけどなぁ。)の影響範囲の調査方法について」が掲載されました。ルイージ@お化け屋敷のような、次から次へと襲い掛かってくる問合せの嵐に困っています。脆弱性を機に、緊急コラムとして調査方法を説明することにしました。一昨日考えた内容を急いでダンプしたものなので、全てを網羅できている訳ではありません。影響範囲を調査することの難しさに気付いて素直にアップデートをしていただけるのなら、この記事を作成した意味はあると考えています。今回の脆弱性については幽霊に振り回されすぎている感がありますが、システムの動作を再確認してみるチャンスかもしれません。任意のホスト名を渡すことができるかどうかをソースコードレベルで網羅的に調査してみたら、OSコマンドインジェクションのような、今まで見落としていた脆弱性が見つかってもおかしくないと思っています。ススメ」が掲載されました。使って挙動を追跡するというお話です。起動してから約70秒後にシステムが予期せぬ再起動をしてしまうというトラブルが発生していました。タイムアウトによるリセットが発生しているのではないかと疑ったのですが、原因を掴めませんでした。スクリプトを仕掛けて事象を再現してもらいました。書き込んだことによるリセットが発生していたことが判明したのです。これをきっかけに、設定の誤りが予期せぬ再起動の原因であったことが判明し、トラブルを解決することができました。呼び出しているようです。書き込んでいるようです。デーモンにログメッセージを出力する方法には、2つの落し穴があったのです。デフォルトで非同期書き込みを行うようになっている点です。そのため、非同期書き込み後すぐに再起動要求が発生してしまっては、ログに残すことができません。関数が復帰してしまうため、たとえ同期書き込みを行うようになっていたとしても、同期書き込みの完了を待たずに再起動要求が発生してしまい、ログに残すことができません。登場により、3つ目の落し穴も発見されました。行われなくなっています。ログが残っていないという可能性が一層高くなっています。デーモンに頼っていては駄目なのかもしれません。システムが増えてくるに従い、問題事象発生時のログを如何に残すかという課題が出てきそうです。経由で取得するという方法が使えます。アップデートは〜内〜。ススメ」が掲載されました。風のプロセス実行履歴を埋め込むというお話です。メインラインカーネルへのマージを目指してMLに提案中ですので、コードの内容が若干変化しています。興味のある方は、MLでの議論に参加してコメントを頂けると嬉しいです。ススメ」が掲載されました。今回は犯人探しのお話です。社のサポートが受けられる標準機能なので気軽に試せるかと思います。熊猫はコーヒーブレークの内容にはノータッチなのですが、今回のコーヒーブレークの内容には突っ込みを入れておこうと思います。問題を解決するのに必要な情報が提供されない理由のひとつに、「サポート技術者が何をもとに調査や解析を行うかがあまり知られていない」ことにあるという点は同意します。問題が起きたときに、「どんな問題が起きているのか判らない」「どこに必要な情報が保存されているのか判らない」「どうすれば必要な情報を取得できるのか判らない」「トラブルの発生後に情報取得のツールやコマンドを提示されても、すぐに使いこなせるとは限らない」など、「製品別に調査に必要な情報の一覧を作っておくだけでは対処できない」部分も多いと思うのです。OSSであってもシステムの安定稼働とセキュリティが年々重要視されてきている中で、お客様がトラブルに遭遇したときに自力で情報収集や一次切り分けができるスキルをどうやって共有/継承していくのかという「教育」の問題でもあり、問題解決のお手伝いをする組織としてどう対処していくのかを考え続けなければいけない課題でもあると思うのです。熊猫が安心して年次有給休暇を取得できるようになるためにも、ね。ススメ」が掲載されました。今回は誰かの行動を一つ残らず追いかけるという話です。知世ちゃんのことを思い出したので、「歓びのキャロル」を聞きながらこちらの補足記事を書いています。普通に使われていると思うので、特別な内容は無いです。ログを頼りに問題事象の解析を行う調査担当者の立場としては、「事象の再現手順を確立する」「事象の発生時刻が判るようにする」という基本事項の繰り返しです。今年もいろいろなバグや脆弱性に振り回され続けてきました。(18年前!)から存在している(と考えられる)脆弱性」により引き起こされる様々な問題事象に関して、脆弱性の修正方法を議論して修正内容がバックポートされるまでの間ずっと無防備になることを避けるために、いくつかの問題事象を先に修正してもらえるよう試行錯誤していました。してしまう事象に関して、脆弱性を使わずに事象を再現させるプログラムを作成して投稿したところ、関係者からのコメントを頂くことができ、衝撃の事実が明らかになりました。乗り換えを真剣に検討し始めるだろう」という冗談が飛び出すような、とんでもない相違が存在していたのです。これじゃあ、システムがロックアップしてしまうのも不思議ではないですねぇ。やって修正するのか、これから延々と議論が続くことになりそうです。セカンドシーズン、素敵なアニメでした。第10回「ソースコード閲覧ノススメ」が掲載されました。今回はディストリビューションに同梱されているプログラムのソースコードの確認手順の話です。ユーザ向けの手順にしてあります。何か問題が発生した時に、ちょっとソースコードを確認すれば、どこで問題が起きているのか/起こりそうかが判明することが少なからずあります。解析ツールを使用することで原因を突き止めやすくなります。商用のウイルス対策ソフトや死活監視プログラムのように、ディストリビューションに同梱されていないプログラムを使用している環境では、普段遭遇しないようなエラーコードが返却されたり、フリーズしたり再起動したりするトラブル事例が多いと感じています。残念ながらソースコードを確認できないため、原因不明のまま諦めざるを得ません。各種ウイルス対策ソフトが使っている(リアルタイム検索のための)カーネルモジュール部分のソースコードを閲覧できるようになっていれば、だいぶ状況は良くなりそうなのになぁ・・・。第9回「アップデートノススメ」が掲載されました。おけるソフトウェアの管理の話です。ススメ」となる予定でした。今年も大型脆弱性が続々と発見されているのに、相変わらず「アップデートしないで済む根拠」を確認するための問合せが目立っており、どうも「アップデートすることを必要以上に恐れすぎているのではないか」と思えるのです。「リグレッションに遭遇して動かなくなるのが怖い」のか「個々のプログラムや設定がどこでどのように影響しあっているかを知らないから怖い」のかは判りません。前者なら変更履歴とソースコードとの照合を行うとか、後者なら自分が管理しているシステムについて理解しようと努力するとか、塩漬けにする以外に何かできることはあると思います。オープンソースを使ったシステムがブラックボックスのままだなんて、モッタイナイ。第8回「カーネルパラメーターチューニングノススメ」が掲載されました。今回はカーネルパラメータチューニングです。予期せぬ再起動や系切り替えが発生する前に何とかして手がかりを得ようと試行錯誤を続けた結果として「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」という資料ができました。役に立つかもしれないということに気が付きました。あろうと、システムを再起動するための関数呼び出しが発生したらカーネルパニックを発生させます。取得して解析することができる筈ですから。仕掛けられないケースもあります。熊猫自身は問題事象の発生する環境を持ち合わせていないため、どれくらい効果があるのかは不明です。