春らしい花粉に苛まれる日も増え、日本にもたくさんの
今回は
ちなみに正真正銘の初心者向けのUbuntu講座については、過去に次のような記事を書いていますのでそちらもご参照ください。
- 第463回
「新学生・ 新社会人向けのUbuntuデスクトップ講座2017 」 - 第466回
「新学生・ 新社会人向けのUbuntuサーバー講座2017 」
また、Ubuntuの不具合報告の中心となる
何の不具合なのか・再現性はあるのかを確認する
当たり前のことではありますが、何の不具合なのか
また、再現性があるかどうかで調査の難易度はぐっと変わります。どのような構成で、どのようなソフトウェアを動かしていたときに、どのような手順を実施すれば不具合を発生させられるかを明確にすることをおすすめします。できれば手順もよりコンパクトで再現性の高いものにしておくと、より良い報告になります。
特定の手順を踏むと、特定のアプリケーションが確実に落ちる、なんて不具合なら報告も楽になります。ただし後で紹介するように、Ubuntuにはソフトウェアがクラッシュしたら自動的に障害情報を収集・
特定のソフトウェアがはっきりしていたら、それに紐づくパッケージ名を調べましょう。Ubuntuの不具合報告は、パッケージ単位での報告となります。たとえば特定の実行ファイルだとわかっているなら、次のようなコマンドでパッケージ名がわかります。
$ dpkg -S 実行ファイル名
もし見つからないようなら、フルパスで検索しましょう。ちなみに最近のUbuntuは、/bin
」/sbin
」/usr/
」/usr/
」/usr/
」/bin/
」dpkg -S /usr/
」dpkg -S /bin/
」
この手順で判明したのは
ソースパッケージ名の確認方法は簡単です。次のようにapt show バイナリパッケージ名
」
$ apt show バイナリパッケージ名 Package: バイナリパッケージ名 Version: バージョン Priority: important Section: editors Source: ソースパッケージ名 Origin: Ubuntu (以下略)
「Source:
」Source:
」
既知の不具合か探してみよう
パッケージ名がわかったら、次は既知の不具合か調べてみましょう。もしかしたらそこに回避策も載っているかもしれません。Ubuntuの各パッケージの不具合報告は次のURLにまとめられています。
https://bugs.launchpad.net/ubuntu/+source/ソースパッケージ名
この不具合報告は、優先度・
もし、明確なエラーメッセージがわかっているのであれば、メッセージで検索したほうがはやい場合もあります。Googleだと次のような内容で検索すると良いでしょう。
"エラーメッセージをダブルクオーテーションでくくる" site:bugs.launchpad.net
エラーメッセージで検索する場合、タイムスタンプ等を省いておきましょう。たとえば、次のようなエラーメッセージを検索する場合に、いくつかのポイントが存在します。
4月 03 17:27:30 nuc pulseaudio[2680]: org.freedesktop.DBus.Properties.Get /org/bluez/hci0/dev_20_74_CF_BC_96_A7/sep1/fd0 Volume failed: org.freedesktop.DBus.Error.InvalidArgs: No such property 'Volume'
上記は本来1行なのですが、説明しやすいように長い行を折り返しています。
まず最初の4月 03 17:27:30 nuc
」/org/
」
"org.freedesktop.DBus.Properties.Get" "Volume failed: org.freedesktop.DBus.Error.InvalidArgs: No such property 'Volume'"
ダブルクオーテーションでくくった文字列をふたつにしましたが、Googleなら間を*
」
「site:bugs.
」site:ubuntu.
」site:
」
特に一般的なエラーであれば、ArchWiki
ここまで調べても情報が見つからなければ、自分で不具合を報告することになります。
まずはアップストリームへの報告を検討しよう
Ubuntuは様々なソフトウェアの集合体です。リポジトリから提供されるソフトウェアは、それぞれ開発元が存在し、それに対してUbuntuはUbuntu向けのパッチを当ててパッケージングしています。このときあるパッケージの開発元を、Ubuntuでは
見つけた不具合がもしアップストリームでも
- アップストリームの開発者のほうがそのソフトウェアに詳しいため、より
「正しい」 解決策を導ける可能性がある - アップストリームで修正されると、Ubuntu以外のユーザーも恩恵を受けられる
ただし次のような問題もあります。
- Ubuntu固有の事象かもしれないため、アップストリームの開発者の環境では再現できない可能性がある
- アップストリームの修正がUbuntuに反映されるまでタイムラグがある
前者の問題については、報告時に再現環境を明示していれば、開発者側で汲み取ってくれるケースも多いです。ただしできれば、アップストリームの最新版でも再現するかどうかを確認しておいたほうが話がスムーズに進みます。また、Ubuntuのバージョンが古く、最新版では解決済みというケースもあります。この場合は、Ubuntuに該当するパッチを取り込むよう依頼する手順が必要です。
後者のほうがより影響が大きな問題でしょう。アップストリームの新しいバージョンで修正されたとしても、それが取り込まれるのはUbuntuの開発版だけです。いくつかの例外はあるものの、Ubuntuはリリース後にソフトウェアのバージョンをあげることはありません。もし修正した内容を、Ubuntuのリリース済みのバージョンにも適用したい場合は、不具合を修正する必要最小限のパッチを作成し、それを取り込む必要がでてきます。
Ubuntuで不具合を報告するには
さて、ようやくUbuntuへ不具合を報告する時間です。報告方法は次の3パターン存在します。
- クラッシュ時に表示されるインターフェースから報告する
ubuntu-bug
コマンドを使って特定のパッケージについて報告する- LaunchpadのWeb UIから報告する
順番に見ていきましょう。
クラッシュ時に表示されるインターフェースから報告する
Ubuntu上のソフトウェアがクラッシュするとLinuxカーネルの/proc/
という仕組みを経由して、Apportによって障害情報が収集されます。これは/var/
以下にアーカイブされて保存されますが、Ubuntuデスクトップの場合、次のような画面が表示されて、障害情報を報告可能です。
ここで
「送信しない」/var/
」ubuntu-bug /var/
」
ちなみに毎回障害情報を送信するかどうか聞かれたくない場合は、次のコマンドで問い合わせを無効化できます。
$ gsettings set com.ubuntu.update-notifier show-apport-crashes false
そもそも障害情報を収集したくない場合は、/etc/
のenabled
を
# set this to 0 to disable apport, or to 1 to enable it # you can temporarily override this with # sudo service apport start force_start=1 enabled=0
変更後にsudo systemctl restart apport.
」
ubuntu-bug
コマンドを使って特定のパッケージについて報告する
クラッシュしない不具合についても、ubuntu-bug
コマンドで報告できます。この場合は、再現手順等を自分でまとめて報告する必要があります。
まず、あらかじめ
アカウントを作成したら、問題となるソフトウェアのPID
$ ubuntu-bug PIDもしくはパッケージ名
すると管理者権限を要求したあとに、システム情報を収集し、次のようなダイアログが立ち上がります。
ここで送信ボタンを押すと、ウェブブラウザーが開き、Launchpadの報告画面に遷移します。
タイトルを入力して
不具合の概要は、他の開発者が最初に参考にする情報です。情報は多すぎず少なすぎず、さらにわかりやすく英語で書いておくことが求められます。とは言うものの、最初は塩梅がわからないでしょう。画像にざっくりとテンプレートを書いておいたので、そちらも参照してください。
「This bug is a security valnerability」
ちなみにubuntu-bug
コマンドは、サーバー版でも利用可能です。この場合、情報をアップロードしたあとに報告用のURLが表示されます。あとはそのURLに任意のマシンのブラウザーからアクセスすればOKです。
LaunchpadのWeb UIから報告する
ubuntu-bug
コマンドを使わずに直接Web UIから報告することも可能です。ただし、これは
不具合を報告する場合、次のようなURLにアクセスします。
https://bugs.launchpad.net/ubuntu/+source/ソースパッケージ名/+filebug
あとのUIはubuntu-bug
を使った時と同じです。
報告したそのあとは
不具合報告は重要です。SNSに不具合をツイートするだけで、修正されることはまずありません。もし修正されたのだとしたら、開発者がよほどそのSNSが大好きか、ものすごく運が良かった特殊ケースと考えるべきです。そんなところで限りある運を使い果たすぐらいなら、個々のソフトウェアの正しい手順を踏んで、不具合を報告しましょう。
多少手順を踏み外していても、誠実な対応を心がければ、大抵の開発者は笑ってフォローしてくれます[2]。それよりは報告されることが重要なのです。
ただし残念なことに、たとえ完璧な報告であっても、報告しただけで作業が止まってしまうことも多々あります。その場合は、たとえばアップストリーム側で修正した際のコミットがわかっているならそのURLを貼り付けたり、Ubuntuコミュニティのメーリングリストやフォーラムで
もっと強力な手段は、自分で修正してしまうことです。これは慣れるまで相応の時間がかかりますが、慣れてしまえばそれなりに応用が効くノウハウとなります。まずは対象となるソフトウェアについてある程度の状況を把握し、次にUbuntuの
いずれにせよ、