Ubuntu

Ubuntu18.04 ログイン直後のエラー表示

最近、Ubuntuのデスクトップにログインするたびに「システムプログラムの問題が見つかりました」っていうダイアログが表示されるようになっている。

しばらく表示される日々が続き、ある時から表示されなくなる…これは一体!?



広告


何を契機にダイアログが表示され、何故起動のたびに表示されるのか、何故あるときから表示されなくなるのかというところが知りたい。

このくらい調べたところで、だいたい満足。

結論

2020/09/26 修正
ログイン時に以下の条件に合致するとこのダイアログが表示される模様。
(だけど、このチェック機能が呼び出される仕掛けはわかっていなかったり、ものすごーく浅いソース解析によるので、間違っていたらごめんなさい)

  • /var/crash/〜.crash ファイルがある
  • そのファイルが0バイトを超えている
  • ユーザーID500未満、かつ、そのユーザーの名前がguestではじまらない
  • アクセス日時(atime)が最終変更日時(mtime)より新しい

なので、この条件に一致するcrashファイルを削除すればダイアログは表示されなくなるはず。
どこかのQ&Aにファイルを消してもダイアログが表示される…と書かれていたケースがあったけれども、wikiの説明や今回の浅い解析からは起こり得ないので、何かまた別の条件によるものと思われる。

アクセス日時はちょっと厄介だけれどもviで開くと更新され、viewで開くと更新されない模様。
エス技研 / Linuxのタイムスタンプはmtime、ctime、atimeの3種類。touchコマンドで更新する方法
この記事を見て touch -a でアクセス日時を変更したところ、ダイアログは表示されなくなった。

ただし…なぜしばらくするとダイアログ表示がなされなくなるのかを解明することはできなかった。
やってみたところ、ユーザーで実行したアプリがクラッシュした(この日はChromeが日本語入力中に落ちた)とき、ダイアログ表示がされるようになったので、ディレクトリの変化日時がチェックする・しないの契機になっているのかもしれない。

エラートラッカー

エラーを追跡する仕組みを指してそう呼ぶらしい。

Ubuntuのエラートラッカーはクラッシュ、ハング、重大なエラーなどをエンドユーザーに説明し、報告する。集められた報告は、Ubuntu開発者には最もよくあるエラーとして見える。

仕組み

仕組みについて、ここで説明されていた。
ubuntu wiki / ErrorTracker – Anatomy of a crash, in detail

Apportは問題を検知すると.crashファイルを出力し、apport-gtkを呼び出してダイアログを表示して、ユーザーに問題を報告するかどうか尋ねる。ユーザーが報告することを選択したら、.uploadファイルを書き込む。

Whoopsieは/var/crashディレクトリにinotifywatchを設定し、.uploadファイルが表示されたら.crashファイルをhttps://daisy.ubuntu.comにアップロードし、.uploadedファイルを作成する。

Daisyは報告をCassandraデータベースに書き込み、まだ誰からもコアダンプを受け取っていなければWhoopsieにコアダンプを要求する。Whoopsieはコアダンプを送信し、Daisyはそれを保管してRabbitキューに入れる。最終的には、この問題を経験したユーザーの数がエラーサイトに表示される。

クライアント側の仕組みは比較的簡単なものなのかなと思われる。また、報告に当たって必ずコアダンプを送るわけでもなさそうで、情報を送信してもあまり問題ない…というか、むしろ多発!と認識してもらったほうが優先度が上がりそうなので送信したほうがいいと思った。

Apport

そもそもこれは何者なのか、というところから知らなかったりして。
pc.casey.jp / Ubuntu 12.04 LTS 「システムプログラムの問題が見つかりました」

これはApportというのね。
ubuntu wiki / Apport

クラッシュとOS環境に関する情報を収集し、クラッシューをユーザーに通知してどうするのかを尋ねる画面を表示するものらしい。

収集場所は /var/crash で、確かにファイルがあった。
_usr_bin_fcitx-dbus-watcher.1000.crash
_usr_bin_rhythmbox.1000.crash

説明を読み進めていくと、デフォルトでapportが無効になっている、と書かれているが、いやいやそんなことないでしょ…

$ systemctl status apport
● apport.service - LSB: automatic crash report generation
   Loaded: loaded (/etc/init.d/apport; generated)
   Active: active (exited) since Sun 2020-09-20 14:41:24 JST; 5h 5min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1028 ExecStart=/etc/init.d/apport start (code=exited, status=0/SUCCESS)

開発者向けに書かれているのかな。

Whoopsie

Ubuntu 18.04 MATEにはインストールされているが、Ubuntu 18.04 Serverにはインストールされていなかった。

最後に調べりゃいいや…と思っていたのだが、これで今までの理解がひっくり返されたような。だって、レポートを送るのはwhoopsieの役割じゃないの!?

まぁ、でも、Apportにも報告機能(apport-bug)があるから、whoopsieは必ずしも必要なわけじゃないのかもしれない。

Apportの構成

manpageを探してみたけれどもApportというのはなかった。理解するのに時間がかかりそうな予感。

コマンド

apport-なんちゃら の集合体っぽい感じ。構成をざっくり見ようと思い…

$ dpkg -L apport | grep bin
/usr/bin
/usr/bin/apport-bug
/usr/bin/apport-cli
/usr/bin/apport-unpack
/usr/bin/apport-collect
/usr/bin/ubuntu-bug

これらのコマンド群で構成されているらしい。

コマンド機能備考
apport-bugバグ追跡システムに問題を報告する。
apport-cliクラッシュ情報を開発者に送信するためのフロントエンド。
主にサーバーで利用することを目的としている。
apport-gtk, apport-kdeがある。
apport-unpack問題報告をファイル分割する。
apport-collectapport-bugと同じ情報を収集するが、送信済みの報告に追加される形になる。ちょっとよくわからない。
ubuntu-bugシンボリックリンク。
/usr/bin/ubuntu-bug -> apport-bug
manでapport-bugが表示される。

確認してみると、apport-gtkがインストールされていた。

$ dpkg -l apport*
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留
|/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常)
||/ 名前                バージョン     アーキテクチャ 説明
+++-===================-==============-==============-===========================================
ii  apport              2.20.9-0ubuntu all            automatically generate crash reports for de
ii  apport-gtk          2.20.9-0ubuntu all            GTK+ frontend for the apport crash report s
un  apport-kde          <なし>         <なし>         (説明 (description) がありません)
ii  apport-symptoms     0.20           all            symptom scripts for apport

デスクトップはMATEなので、apport-gtkがインストールされているのは必然か。
apport-bugを実行するとGUIが表示される。

設定ファイル

設定をなんとなく調べてみる。

$ dpkg -L apport | grep ^/etc/.*
/etc/apport
/etc/apport/blacklist.d
/etc/apport/blacklist.d/README.blacklist
/etc/apport/blacklist.d/apport
/etc/apport/crashdb.conf
/etc/bash_completion.d
/etc/bash_completion.d/apport_completion
/etc/cron.daily
/etc/cron.daily/apport
/etc/default
/etc/default/apport
/etc/init.d
/etc/init.d/apport
/etc/logrotate.d
/etc/logrotate.d/apport

これらをチラチラ見てみる。

ファイル内容備考
/etc/apport/crashdb.conf
/etc/bash_completion.d/apport_completionapportに関するコマンド補完の設定。
/etc/apport/blacklist.d/apport
/etc/default/apportenabledという設定値があり、1が書かれていた。
0にするとapportを無効化できる。
設定値が0でも、以下で一時的に起動できると書かれているが、うまく行かなかった。
sudo service apport start force_start=1
/etc/cron.daily/apport1週間経った報告を破棄。/etc/crontabを見たら、cron.dailyは朝の6:25に実行される。
その時間帯はPCが起動してないかも…
/etc/logrotate.d/apport日々実行され、履歴は7回分残る。今日+過去7日。
/etc/init.d/apportrcスクリプト。
/etc/default/apportを実行して環境変数enabledを設定させている。
force_start=1は環境変数に入れておく!?

と、まぁ、だいたいこんなところか。

bash_completionというのは初めて見た。
tabによる補完はかなり多用しているのだけれど、設定を見たことはなかった。
ユーザーが使いやすいように面倒な定義を定義をしてくれているようだけれど、中身の勉強はまた今度。
ubuntu manpage / bash ※項目 Programmable Completion

/etc/default/apport の設定で状態を変えられるとのことだが…

■enabled=1の場合
$ systemctl status apport
● apport.service - LSB: automatic crash report generation
   Loaded: loaded (/etc/init.d/apport; generated)
   Active: active (exited) since Mon 2020-09-21 01:51:00 UTC; 15s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 839 ExecStart=/etc/init.d/apport start (code=exited, status=0/SUCCESS)

Sep 21 01:51:00 temp systemd[1]: Starting LSB: automatic crash report generation...
Sep 21 01:51:00 temp apport[839]:  * Starting automatic crash report generation: apport
Sep 21 01:51:00 temp apport[839]:    ...done.
Sep 21 01:51:00 temp systemd[1]: Started LSB: automatic crash report generation.

■enabled=0の場合
$ systemctl status apport
● apport.service - LSB: automatic crash report generation
   Loaded: loaded (/etc/init.d/apport; generated)
   Active: active (exited) since Mon 2020-09-21 01:44:45 UTC; 51s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 823 ExecStart=/etc/init.d/apport start (code=exited, status=0/SUCCESS)

Sep 21 01:44:45 temp systemd[1]: Starting LSB: automatic crash report generation...
Sep 21 01:44:45 temp systemd[1]: Started LSB: automatic crash report generation.

わかりにくいけれども、apportの開始についてログに出るか、出ないか、で判断するっぽい。
動作しているのかどうかを見分けるのがこれだとして、force_start=1を入れても、環境変数に設定してもうまいこと起動することができなかった。

思ったこと

ログイン直後に毎度メッセージが表示されるのは鬱陶しい、ということで情報を探してみた。

最初に見つかったのがクラッシュレポートを削除して、/etc/default/apportのenabledを0に設定する…という解決策。
enabled=0は一時的な設定、としているケースもあるようだけれども、書き換えたらもとに戻る契機はないかもしれない。

Whoopsieの構成

ServerにWhoopsieがインストールされていないことから、調査省略せずに調べてみようと思った。時間が立っていて仕組みが変わっているとか、仕組みの理解が足りないとかいった可能性を排除したい。

コマンド

コマンドは1つだった。

$ dpkg -L whoopsie | grep bin
/usr/bin
/usr/bin/whoopsie

$ whoopsie --help
Usage:
  whoopsie [OPTION?]

Help Options:
  -h, --help              Show help options

Application Options:
  -f, --foreground        Run in the foreground
  -a, --assume-online     Always assume there is a route to $CRASH_DB_URL.

man pageがなく、help表示してみたけれども何者だか分からない。

設定ファイル

設定を見てみよう。

$ dpkg -L whoopsie | grep ^/etc/.*
/etc/init
/etc/init/whoopsie.conf
/etc/init.d
/etc/init.d/whoopsie

これもチラチラ見てみる。

ファイル内容備考
/etc/init/whoopsie.confUpstartのスクリプト。
ネットワーク接続を待って、whoopsie -f を実行。
使われていない。
/etc/init.d/whoopsiercスクリプト。
whoopsie -f を実行している。
報告先
https://daisy.ubuntu.com

/etc/init にあるスクリプトはUpstartのスクリプトのようだが、upstartはインストールされていないので、使われていないだろう。

動作のために環境変数が使われたりするみたいだけれども、設定ファイル等は持たない模様。Launchpadまで行ってみてけれども、モジュールの概要説明も簡単なもので、はっきりとはわからなかった。

Apportに関するドキュメントのなんちゃって翻訳

やっぱうまく理解できないので、/usr/share/doc/apport にある情報を読んでみた。
Google先生に翻訳してもらおう。

README

/usr/share/doc/apport/README

Apport crash detection/reporting
================================

Apport intercepts Program crashes, collects debugging information about
the crash and the operating system environment, and sends it to bug trackers in a
standardized form. It also offers the user to report a bug about a package,
with again collecting as much information about it as possible.
Apportはプログラムのクラッシュをインターセプトし、クラッシュと
オペレーティングシステム環境に関するデバッグ情報を収集して、標準化された形式で
バグトラッカーに送信します。また、パッケージに関するバグを報告するように
ユーザーに提供し、パッケージに関する情報をできるだけ多く収集します。

It currently supports
現在サポートされているのは

 - Crashes from standard signals (SIGSEGV, SIGILL, etc.) through the kernel
   coredump handler (in piping mode)
   カーネルコアダンプハンドラ(パイピングモード)を介した標準シグナル
  (SIGSEGV、SIGILLなど)からのクラッシュ
 - Unhandled Python exceptions
   未処理のPython例外
 - GTK, KDE, and command line user interfaces
   GTK、KDE、およびコマンドラインユーザーインターフェイス
 - Packages can ship hooks for collecting specific data (such as
   /var/log/Xorg.0.log for X.org, or modified gconf settings for GNOME
   programs)
   パッケージは、特定のデータ(X.orgの/var/log/Xorg.0.log、またはGNOMEプログラムの
   変更されたgconf設定など)を収集するためのフックを出荷できます。
 - apt/dpkg and rpm backend (in production use in Ubuntu and OpenSUSE)
   apt / dpkgおよびrpmバックエンド(UbuntuおよびOpenSUSEで本番使用)
 - Reprocessing a core dump and debug symbols for post-mortem (and preferably
   server-side) generation of fully symbolic stack traces (apport-retrace)
   コアダンプを再処理し、完全にシンボリックなスタックトレース(apport-retrace)の
   事後(できればサーバー側)生成のためにシンボルをデバッグする
 - Reporting bugs to Launchpad (more backends can be easily added)
   Launchpadにバグを報告する(より多くのバックエンドを簡単に追加できます)

Please see https://wiki.ubuntu.com/Apport for more details and further links.
The files in doc/ document particular details such as package hooks, crash
database configuration, or the internal data format.
詳細およびリンクについては、https://wiki.ubuntu.com/Apportを参照してください。
doc/ 内のファイルは、パッケージフック、クラッシュデータベース構成、
内部データ形式などの特定の詳細を文書化します。

Temporarily enabling apport
===========================

The automatic crash interception component of apport is disabled by default in
stable releases for a number of reasons [1].  To enable it just for the current
session, do
apportの自動クラッシュインターセプトコンポーネントは、さまざまな理由により、
安定版リリースではデフォルトで無効になっています[1]。 
現在のセッションでのみ有効にするには、次のようにします。

  sudo service apport start force_start=1

Then you can simply trigger the crash again, and Apport's dialog will show up
with instructions to report a bug with traces. Apport will be automatically
disabled on next start.
その後、再度クラッシュをトリガーするだけで、Apportのダイアログに、
トレース付きのバグを報告する手順が表示されます。 Apportは次回の起動時に自動的に無効になります。

If you are triaging bugs, this is the best way to get traces from bug reporters
that didn't use Apport in the first place.
バグをトリアージする場合、これは、最初にApportを使用しなかったバグレポーターからトレースを取得するための最良の方法です。

To enable it permanently, do:
恒久的に有効にするには、こうします。

  sudo nano /etc/default/apport

and change enabled from "0" to "1".

[1] https://wiki.ubuntu.com/Apport#How%20to%20enable%20apport

Crash notification on servers
=============================

You can add
追加可能です。

if [ -x /usr/bin/apport-cli ]; then 
    if groups | grep -qw admin && /usr/share/apport/apport-checkreports -s; then
	cat <<-EOF
	You have new problem reports waiting in /var/crash. 
	To take a look at them, run "sudo apport-cli".

	EOF
    elif /usr/share/apport/apport-checkreports; then
	cat <<-EOF
	You have new problem reports waiting in /var/crash. 
	To take a look at them, run "apport-cli".

	EOF
    fi
fi

to your ~/.bashrc to get automatic notification of problem reports.
~/.bashrcに追加して、問題レポートの自動通知を取得します。

Contributing
============

Please visit Apport's Launchpad homepage for links to the source code revision
control, the bug tracker, translations, downloads, etc.:
ソースコードのリビジョン管理、バグトラッカー、翻訳、ダウンロードなどへのリンクについては、
ApportのLaunchpadホームページにアクセスしてください。

  https://launchpad.net/apport

The preferred mode of operation for Linux distribution packagers is to create
their own branch from 'trunk' and add the distro specific packaging and patches
to it. Please send patches which are applicable to trunk as merge requests or
bug reports, so that (1) other distributions can benefit from them as well, and
(2) you reduce the code delta to upstream.
Linuxディストリビューションパッケージャーの推奨される操作モードは、「トランク」から
独自のブランチを作成し、ディストリビューション固有のパッケージとパッチを追加することです。
トランクに適用可能なパッチをマージ要求またはバグレポートとして送信してください。これにより、
(1)他のディストリビューションでも同様にそれらの恩恵を受けることができます。
(2)コードデルタをアップストリームに減らすことができます。

 

crashdb-conf.txt

/usr/share/doc/apport/crashdb-conf.txt

Principal CrashDB conf file
===========================

The file is located in /etc/apport/crashdb.conf .
ファイルは /etc/apport/crashdb.conf にあります。

This file contains information about the Crash Databases to use when sending a
crash report.  Here is an excerpt of the file:
このファイルには、クラッシュレポートを送信するときに使用する
クラッシュデータベースに関する情報が含まれています。 ファイルの抜粋を次に示します。

+-----------------

default = 'ubuntu'

databases = {
    'ubuntu': { 
        'impl': 'launchpad',
        'distro': 'ubuntu'
        'bug_pattern_url': 'http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml',
        'dupdb_url': 'http://people.canonical.com/~ubuntu-archive/apport-duplicates',
    },
}
+-----------------

The 'default' parameter is used to specify the default database to use when
getting a crash report.  It's one of the names used as a label in the databases
dictionary. Please note that package hooks can change the database to report to
by setting the "CrashDB" field; please see package-hooks.txt for details of
this.
'default'パラメータは、クラッシュレポートを取得するときに使用する
デフォルトデータベースを指定するために使用されます。 
これは、データベースディクショナリでラベルとして使用される名前の1つです。
パッケージフックは、「CrashDB」フィールドを設定することにより、
レポートするデータベースを変更できることに注意してください。 
詳細については、package-hooks.txtを参照してください。

Standard options
================

All crash database implementations support the following options:
すべてのクラッシュデータベースの実装は、次のオプションをサポートしています。

 - bug_pattern_url: URL to an XML file describing the bug patterns for this
   distribution. This can match existing bugs to arbitrary keys of a report
   with regular expressions, to prevent common problems from being reported
   over and over again. Please see apport.Report.search_bug_patterns() for the
   format.
   このディストリビューションのバグパターンを説明するXMLファイルのURL。
   これにより、既存のバグを正規表現を使用してレポートの任意のキーに一致させ、
   一般的な問題が繰り返し報告されるのを防ぐことができます。
   形式については、apport.Report.search_bug_patterns()を参照してください。

 - dupdb_url: URL for the duplicate DB export, to prevent already known crashes
   from being reported again. This can be generated from an existing duplicate
   database SQLite file with "dupdb admin publish" (see manpage) or with the
   --publish-db option of crash-digger.
   既知のクラッシュが再度報告されないようにするための、複製DBエクスポートのURL。
   これは、「dupdb admin publish」(マンページを参照)またはcrash-diggerの
   --publish-dbオプションを使用して、既存の複製データベースSQLiteファイルから生成できます。

 - problem_types: List of "ProblemType:" values that this database accepts for
   reporting. E. g. you might set
   このデータベースがレポートのために受け入れる「ProblemType:」値のリスト。
   例: あなたは設定するかもしれません

     'problem_types': ['Bug', 'Package']

   to only get bug and package failure reports reported to this database,
   but not crash reports. If not present, all types of problems will be
   reported.
   このデータベースに報告されたバグおよびパッケージの障害レポートのみを取得し、
   クラッシュレポートは取得しません。 
   存在しない場合は、すべてのタイプの問題が報告されます。

Third Parties crashdb databases
===============================

Third party packages can also ship a set of databases to use with Apport. Their
configuration files should be located in /etc/apport/crashdb.conf.d/ and end
with ".conf".
サードパーティのパッケージは、Apportで使用するデータベースのセットを出荷することもできます。
それらの構成ファイルは/etc/apport/crashdb.conf.d/にあり、「.conf」で終わる必要があります。

Here is an example /etc/apport/crashdb.conf.d/test.conf file:
これはファイルの例です。

+-----------------

mydatabase = { 
        'impl': 'mycrashdb_impl',
	    'option1': 'myoption1',
	    'option2': 'myoption2'
    }
mydatabase1 = { 
        'impl': 'mycrashdb_impl',
	    'option1': 'myoption3',
	    'option2': 'myoption4'
    }   
+-----------------

The databases specified in this file will be merged into the 'databases'
dictionary. The result is the equivalent of having the principal file:
このファイルで指定されたデータベースは、「データベース」辞書にマージされます。
結果は、プリンシパルファイルを持つのと同じです。

+-----------------------

default = 'ubuntu'

databases = {
    'ubuntu': { 
        'impl': 'launchpad',
        'bug_pattern_url': 'http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml',
	'distro': 'ubuntu'
    },
    'mydatabase': { 
        'impl': 'mycrashdb_impl',
	    'option1': 'myoption1',
	    'option2': 'myoption2'
    },
    'mydatabase1': { 
        'impl': 'mycrashdb_impl',
	    'option1': 'myoption3',
	    'option2': 'myoption4'
    }
}
+-----------------------

Crash database implementations
==============================

 * "launchpad" uses bug reports against https://launchpad.net, either projects
   or distribution packages.
   「launchpad」は、プロジェクトまたは配布パッケージのいずれかで、
   https://launchpad.netに対するバグレポートを使用します。

   Options:
   - distro: Name of the distribution in Launchpad
     Launchpadのディストリビューションの名前
   - project: Name of the project in Launchpad
   (Note that exactly one of "distro" or "project" must be given.)
     Launchpad内のプロジェクトの名前
   (「ディストリビューション」または「プロジェクト」のどちらか一方のみを指定する必要があることに注意してください。)
   - staging: If set, this uses staging instead of production (optional).
     This can be overriden or set by $APPORT_STAGING environment.
     設定されている場合、本番ではなくステージングが使用されます(オプション)。
     これは、$APPORT STAGING環境によってオーバーライドまたは設定できます。
   - cache_dir: Path to a permanent cache directory; by default it uses a
     temporary one. (optional). This can be overridden or set by
     $APPORT_LAUNCHPAD_CACHE environment.
     永続的なキャッシュディレクトリへのパス。 デフォルトでは一時的なものを使用します。(オプション)。
     これは、$APPORT_LAUNCHPAD_CACHE環境によってオーバーライドまたは設定できます。
   - escalation_subscription: This subscribes the given person or team to
     a bug once it gets the 10th duplicate.
     これは、指定された人またはチームが10番目の重複を取得するとバグを申し込みします。
   - escalation_tag: This adds the given tag to a bug once it gets more
     than 10 duplicates.
     これにより、重複が10を超えると、指定されたタグがバグに追加されます。
   - initial_subscriber: The Launchpad user which gets subscribed to newly
     filed bugs (default: "apport"). It should be a bot user which the
     crash-digger instance runs as, as this will get to see all bug
     details immediately.
     新しく提出されたバグにサブスクライブするLaunchpadユーザー(デフォルト: "apport")。
     これは、すべてのバグの詳細をすぐに確認できるため、crash-diggerインスタンスを実行する
     ボットユーザーである必要があります。
   - triaging_team: The Launchpad user/team which gets subscribed after
     updating a crash report bug by the retracer (default:
     "ubuntu-crashes-universe")
     リトレーサーによるクラッシュレポートバグの更新後に申し込まれる
     Launchpadユーザー/チーム(デフォルト: "ubuntu-crashes-universe")
   - architecture: If set, this sets and watches out for needs-*-retrace
     tags of this architecture. This is useful when being used with
     apport-retrace and crash-digger to process crash reports of foreign
     architectures. Defaults to system architecture.
     設定されている場合、これは、このアーキテクチャーのneeds-*-retraceタグを
     設定して監視します。これは、外部アーキテクチャのクラッシュレポートを
     処理するためにapport-retraceおよびcrash-diggerと共に使用される場合に役立ちます。
     デフォルトはシステムアーキテクチャです。

   Crash reports are always filed as private Launchpad bug. Bug reports are
   public by default, but a package hook can change this by adding a
   "LaunchpadPrivate" report field (NOT a crashdb option!) with any value, and
   adding a "LaunchpadSubscribe" report field with a list of initial
   subscribers. For example, your package hook might do this:
   クラッシュレポートは、常にLaunchpadのプライベートバグとして報告されます。 
   バグレポートはデフォルトで公開されていますが、パッケージフックは、
   任意の値で「LaunchpadPrivate」レポートフィールド(crashdbオプションではありません)を追加し、
   初期サブスクライバーのリストを含む「LaunchpadSubscribe」レポートフィールドを追加することで、
   これを変更できます。 たとえば、パッケージフックは次のようになります。

   def add_info(report):
       report['LaunchpadPrivate'] = '1'
       report['LaunchpadSubscribe'] = 'joe-hacker foobar-dev'

 * "memory" is a simple implementation of crash database interface which keeps
   everything in RAM. This is mainly useful for testing and debugging.
   「メモリ」は、すべてをRAMに保持するクラッシュデータベースインターフェイスの
   単純な実装です。 これは主にテストとデバッグに役立ちます。

   The only supported option is "dummy_data"; if set to a non-False value, it
   will populate the database with some example reports.
   サポートされている唯一のオプションは "dummy_data"です。 
   False以外の値に設定すると、データベースにいくつかのサンプルレポートが入力されます。

 

さいごに

結局消化不良気味…だけど、不具合発生したら情報を送ることで、Ubuntuの品質向上に役立つかもしれないと思った。なんにも作ることはできないので、せめて情報提供で協力するのが大切なのかもしれないなと。

広告

コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他