Red Hatの森若です。
この記事は 赤帽エンジニア Advent Calendar 2018の22日目です。 今回はRHEL 8 Betaの問題をbugzillaにレポートする話をします。
ABRT + systemd-coredump + tuned の組み合わせで起きる問題
「前回systemd-coredumpの話をしたので、次はABRTでcoredump取得してレポートする話を書こうかな……」と思っていたのですが、まさにそこでバグ(っぽい挙動)に遭遇しました。以下に簡単に紹介します。
ABRTはバグレポートを自動でおこなうための仕組みでcoredumpの取得、基本的な解析、レポート作成、bugzillaやカスタマーポータルへの自動投稿を行います。
coredumpの取得をおこなう仕組みがsystemd-coredumpと競合するので、以下のような仕組みで共存しています:
- systemd-coredumpとABRTのコア取得は同じ kernel.core_pattern を利用してフックを仕込んでいる
- systemd-coredumpはシステムのデフォルトとして、/usr/lib/sysctl.d/50-coredump.conf で設定
- 一方ABRTは abrt-install-ccpp-hook スクリプトを実施してサービス起動時に procfs経由で上書きし、systemd-coredumpによる設定は /var/run/abrt/saved_core_pattern バックアップ
- 実際にcore出力をしようとするタイミングで、abrt-ccpp-hookが実行されます。 /etc/abrt/CCpp.conf の MakeCompatCore が no の場合abrtのみで処理を行ない、yesの場合にはsystemd-coredumpでも処理が行われます。
この処理にはまずい点があり、sysctl --system のようにしてsysctl設定をリセットされてしまうとABRTの設定が無効になってしまいます。自動チューニングを行うtunedがsysctlのリセットを実施しています。そのためABRTを有効にしてバグレポートを実施しようとしても、tunedが有効だとABRTのcoredump収集が動作しないという問題が発生します。
バグレポートしよう
問題をみつけたのでレポートしましょう。通常はカスタマーポータルからサポートのケースを開いて対応してもらいますが、今回は問題と再現方法は明らかですし、優先度も高くないのでbugzillaに直接レポートします。
bugzillaはRed Hatのプラットフォーム製品でよく使われているバグトラッキングシステムです。製品によっては社内のJIRAを使っているものもあります。社内で利用されているシステムですが、秘密になっていない部分は一般からアクセスできるようになっています。またFedoraについてはbugzillaが主な問題解決の場となっています。
beta programや、developer programでサポートのない製品を入手した場合には、サポート窓口を利用する権利がありません。このような場合であっても、bugzillaへのレポートは自由に行うことができます。ソフトウェアの問題であるという切り分けは完了している必要がありますし、サポート窓口を経由したレポートのほうが優先度が高くなりますので、通常はサポート窓口へ連絡するのがおすすめです。
bugzillaへのログイン
つい最近bugzillaがアップデートされ、アカウントにRed Hatカスタマーポータルのアカウントを使えるようになりました。右上の「Login」を押して「Red Hat Customer」を押すことでシングルサインオンが実施されます。初回は「Choose/Create an Account」というページが表示され新規にbugzillaのアカウントを作成するか、既存のアカウントをひもづけるかを聞かれます。 カスタマーポータルにアカウントを持っていない・作りたくないという場合には「Open a New Account」からメールアドレスとパスワードでのアカウントを作成して利用できます。
既存ケースの検索
レポートする前に既に同じ問題が登録されていないか探します。とりあえず「Quick Search」のフォームにABRTと入れて検索してみましょう。 ざっと眺めてみると、ABRTの場合は「ABRTで報告した問題」も検索にヒットしてしまうため膨大なリストになり、1000件までで検索が中断されてしまいます。
もう少し細かく指定して検索してみます。メニューから Search → Advanced Search として 製品としてRHEL7,RHEL8を選択し、Componentをabrtとして検索します。今度は21件なので summaryをみて似たケースが既に登録されていないか、似ていそうなものがあれば内容を確認します。
新規ケースの登録
既存のバグで同じ問題が報告されていなさそうだと確認できました。「New」から新規のケースを作成していきます。
「Red Hat」→「Red Hat Enterprise Linux 8」と選択していくと、以下のような画面が出てきます。
Componentはパッケージの場合にはsrc.rpmと同じ名前です。ドキュメントについての問題は doc-ドキュメント名 のようなコンポーネント名が利用されます。 Versionは8.0、Summaryに1行で概要を書き、Descriptionに環境の説明、問題の内容、再現方法などを記載します。今回はありませんが必要に応じて関連するパッチ、ログ、スクリーンショット、外部の関連するbugへのリンクを添付することもできます。 問題を登録すると製品とComponentに対応するメンテナへメールが送られます。
1657158 – In ABRT + systemd-coredump environment, "sysctl --system" disables abrt-hook-ccpp
レポートした後
(カスタマーポータルのケースではなく)bugzillaに直接登録した問題は、すぐに取り扱われるとは限りません。問題が軽微なものであったり、製品リリース上のタイミングによっては、しばらく何の対応もされないケースもあります。急ぐ場合にはサポート窓口からレポートしましょう。
bugzilla上でのやりとりは、「サポート」ではなくエンジニア同士のバグ修正にむけたごく普通のやりとりです。担当のエンジニアが対応するために必要な情報や再現手順を提供し、問題の説明や本来どう動作するべきかなどの意図をはっきりと伝えることが重要です。
やりとりの中で不明点がある場合には、NEEDINFO というフラグをつけたコメントが使われます。これは指定した相手にメールで通知が送られ、追加の情報をリクエストします。自分宛にNEEDINFOのメールがきた時には早い解決のためすぐ対応しましょう。
