私はapportとその使用法について今まで一週間読んでいます。しかし、以下のことを理解できませんでした。
シナリオ:
アプリケーションを開発し、パッケージ化しました。そしてその名前はMyApp.deb
です。バイナリパッケージ名はMyApp
です。アプリケーションはパス/opt/myapplication/bin/MyApp
にインストールされます。
要求:
- アプリケーションがクラッシュしたときに、コアダンプを収集できるようにします。
- 後続の各クラッシュでは、新しいクラッシュを作成する必要がありますが、既存のクラッシュは上書きしません。現在のタイムスタンプなどを使用した自動名前変更などが役立ちます。
- カスタマーマシンにアプリケーションをインストールするとき、インストーラーはシステム全体のパラメーターを変更してはなりません。たとえば、ユーザーの同意なしにシステムパラメータを変更するため、ユーザー/顧客が私のアプリケーションを嫌う可能性があるため、私は彼のコアファイル生成のパターンを変更してはなりません。
- コアファイル生成のパスに問題はありません。現在のディレクトリまたは
/var/crash
のいずれか
私が今までに探索したこと:
Apportは、コアファイルの生成を可能にする素晴らしいユーティリティです。 /proc/sys/kernel/core_pattern
を使用して、コアファイルをフォーマットできます。これにより、コアファイルを定義済みディレクトリにリダイレクトしたり、コアファイルにpidを付けたり、ファイルパスパターンを追加または追加するなどの柔軟性が得られます。Ubuntu以外のパッケージの場合、コアダンプ(レポート)を生成するフックを作成する必要があります。レポートを収集した後、アップロードします。
私が理解できないこと:
- Apportは私が見なければならないものですか??それは私の目的で十分ですか?それとも、他の何かを見るべきですか?
- 私のアプリケーションはどのようなパッケージに該当しますか?私はそれを非ubuntuと呼びますか?第三部?それは何ですか?ドキュメントに異なる用語が表示されますか?
- 前述したように、
MyApp
は/opt/myapplication/bin/MyApp
から実行されるため、コアファイルはどこで生成されますか?現在のディレクトリまたは/var/crash
? Apportは/opt
からトリガーされたクラッシュを検出しますか?解釈しますか? - 重要な質問:アプリケーションを開発し、ApportがレポートをUbuntuリポジトリにアップロードする場合、意味がありません。それでは、Apportにレポートを送信するように指示するにはどうすればよいですか。
- 次のエラーが表示されます:
executable does not belong to a package, ignoring
。だから私は間違っているのですか? - Apportがパッケージを認識するためには、ソースパッケージにする必要がありますか?必須ですか?バイナリパッケージを作成したいだけですか?
- また、Apportが認識する文書のどこかを見ました:
- Ubuntuパッケージまたは
- Launchpadアプリケーションですが、私のアプリケーションはこれらのいずれでもありません。それでは、Apportは現在のシナリオでどのように役立ちますか?