執筆者:角馬 文彦
調べたキッカケ
先日コアダンプファイルを見ようとして気付いた事があるのでお話しようと思います。
今回の内容は下記の環境で確認しています。
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.1 LTS Release: 20.04 Codename: focal $ uname -srvp Linux 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64 $
あるシステムのテスト時に Segmentation fault が発生したのでコアダンプファイル (以下コアファイル)を採取しました。ファイルは core と言う名前で作成されていたのですが、イベントパターンにより何通りか取りたかったので、リネームしても良いのですがコアファイル名の書式を変更する事にしました。コアファイルの書式は
/proc/sys/kernel/core_pattern
にフォーマットを設定する事で変更できます。念の為、現状の書式を確認すると当然 core
になっているのだろうと思いきや
$ cat /proc/sys/kernel/core_pattern |/usr/share/apport/apport %p %s %c %d %P %E $
何と apport と言うコマンドで処理されるようになっていました。余りコアダンプの書式を意識したことが無かったので今まで気付きませんでした。
apport とは
そこで以降では apport について調べた事について書きたいと思います。
そもそも apport が何かと見ますと、インストールされたプログラムの障害発生時に情報を収集して自動的にレポートを送信する仕組みを提供するものでした。 主に Ubuntu の障害解析チームが解析の手掛かりにする為のもののようです。レポートの送信部分の仕組みについてはユーザサイドでは余り役立ちそうに無いので、ここでは障害情報の収集に関わる話に絞って調べました。
apport のパッケージは Ubuntu 11.04 でその片鱗が見られますが 正式には 12.04 から使用されているようです (Apport より)。 他のディストリビューションでは使われていないようです。
パッケージの情報を見ますと提供元は Ubuntu でした。Ubuntu の障害管理の仕組みに則して作成されたものなのでしょう。
apport と言う名前の由来については情報を見つけられませんでした。
パッケージの説明に automatically generate crash reports for debugging
とありますが、これを適当に組み合わせたものでしょうか。
$ apt show apport Package: apport Version: 2.20.11-0ubuntu27.17 Priority: optional Section: utils Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 803 kB Provides: core-dump-handler Depends: python3, python3-apport (>= 2.20.11-0ubuntu27.17), lsb-base (>= 3.0-6), python3-gi, gir1.2-glib-2.0 (>= 1.29.17) Recommends: apport-symptoms, python3-systemd Suggests: apport-gtk | apport-kde, policykit-1 Conflicts: core-dump-handler Breaks: python-apport (<< 2.2-0ubuntu1) Replaces: core-dump-handler, python-apport (<< 2.2-0ubuntu1) Homepage: https://wiki.ubuntu.com/Apport Task: server, ubuntu-desktop-minimal, ubuntu-desktop, cloud-image, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop Download-Size: 129 kB APT-Sources: http://jp.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages Description: automatically generate crash reports for debugging apport automatically collects data from crashed processes and compiles a problem report in /var/crash/. This utilizes the crashdump helper hook provided by the Ubuntu kernel. . This package also provides a command line frontend for browsing and handling the crash reports. For desktops, you should consider installing the GTK+ or Qt user interface (apport-gtk or apport-kde). N: There are 2 additional records. Please use the '-a' switch to see them. $
本家の Debian ではどうかと見ましたが experimental としてあるだけでした。また Debian GNU/Linux 10 (buster) でのコアファイルの書式は下記の通りでした。
$ cat /proc/sys/kernel/core_pattern core $
他の Debiann 系以外のディストリビューションはどうなっているのかと手元の CentOS 7.8 を見てますと下記のようになっておりました。
$ cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h $
こちらはコマンドにパイプしています。パッケージを確認しますと。
$ rpm -qf /usr/libexec/abrt-hook-ccpp abrt-addon-ccpp-2.1.11-57.el7.centos.x86_64 $ rpm -qi abrt-addon-ccpp-2.1.11-57.el7.centos.x86_64 Name : abrt-addon-ccpp Version : 2.1.11 Release : 57.el7.centos Architecture: x86_64 Install Date: 2020年06月19日 08時36分02秒 Group : System Environment/Libraries Size : 353045 License : GPLv2+ Signature : RSA/SHA256, 2020年04月04日 05時48分17秒, Key ID 24c6a8a7f4a80eb5 Source RPM : abrt-2.1.11-57.el7.centos.src.rpm Build Date : 2020年04月03日 00時58分42秒 Build Host : x86-02.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : https://abrt.readthedocs.org/ Summary : abrt's C/C++ addon Description : This package contains hook for C/C++ crashed programs and abrt's C/C++ analyzer plugin. $
確認バージョンは下記になります。
$ cat /etc/redhat-release CentOS Linux release 7.8.2003 (Core) $
これも RedHat 作成の障害情報の提供ツールのようです。それぞれのディストリビューション固有の仕組みに合わせてツールを提供していると言う事なのでしょう。
その他のディストリビューションは確認していませんが興味があれば調べてみて下さい。
取り敢えず apport 無しで
さてコアファイル名の書式ですが、一番簡単なのは前述の /proc/sys/kernel/core_pattern を書き換える事です。
確認にはコアダンプ作成を目的とした下記のソースから作ったバイナリを使用しました。
$ cat segf.c int main(void) { char *p = 0; *p = 1; return 0; } $ gcc -g -Wall -o segf segf.c $
それでは確認してみます。
$ sudo bash -c 'echo core.%p.%i.%t > /proc/sys/kernel/core_pattern' $ ./segf Segmentation fault (core dumped) $ ls core.* core.1507.1507.1621922456 $
問題無く書式通りにコアが作成されています。しかし apport がサービス開始時に /proc/sys/kernel/core_pattern を設定しているので
apport サービスを停止しなければシステム再開時に元に戻ってしまいます。
サービスの状態を確認すると、自動生成された apport.service から
/etc/init.d/apport
が起動されています。
$ systemctl status apport ● apport.service - LSB: automatic crash report generation Loaded: loaded (/etc/init.d/apport; generated) Active: active (exited) since Tue 2021-05-25 02:27:28 UTC; 21min ago Docs: man:systemd-sysv-generator(8) Process: 709 ExecStart=/etc/init.d/apport start (code=exited, status=0/SUCCESS) May 25 02:27:28 ubuntu systemd[1]: Starting LSB: automatic crash report generation... May 25 02:27:28 ubuntu apport[709]: * Starting automatic crash report generation: apport May 25 02:27:28 ubuntu apport[709]: ...done. May 25 02:27:28 ubuntu systemd[1]: Started LSB: automatic crash report generation. $
無効にするには systemd で disable にしても良いのですが、Debian 系のディストリビューションでは通常 /etc/default/ 下にあるデフォルトの設定を読み込み、ある程度、振る舞いを指定できる物もあります。
/etc/init.d/apport を見てみるとやはり /etc/default/apport を展開しています。では /etc/default/apport
を見てみましょう。
$ cat /etc/default/apport # 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=1 $
有りました。enabled=0 に設定すればサービスを無効にできます。よく見ると /etc/init.d/apport 内で
echo "|$AGENT %p %s %c %d %P %E" > /proc/sys/kernel/core_pattern
なる行があるので、サービス起動時にここで更新されていたのですね。もう一つ sysctl の設定を修正する必要があります。
$ sudo sysctl -a | grep core_pattern kernel.core_pattern = core $
/etc/sysctl.conf
に書式を設定します。
$ tail /etc/sysctl.conf # ################################################################### # Magic system request Key # 0=disable, 1=enable all, >1 bitmask of sysrq functions # See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html # for what other values do #kernel.sysrq=438 kernel.core_pattern = "core.%p.%i.%t" $
上記を設定して再起動する事で /proc/sys/kernel/core_pattern が求めていた内容になりました。
apport の振る舞い
それでは次に apport の設定でどうにかならないか見てみる事にします。apport は python で書かれているので直接ソースコードを読む事が出来ます。主なパッケージは下記になります。
$ dpkg -l | grep apport ii apport 2.20.11-0ubuntu27.16 all automatically generate crash reports for debugging ii apport-symptoms 0.23 all symptom scripts for apport ii python3-apport 2.20.11-0ubuntu27.16 all Python 3 library for Apport crash report handling $
障害発生時、カレントディレクトリにはコアファイルが、/var/crash にはコアファイルを含む収集情報ファイル (以下レポート) が置かれます。
但し /var/crash に置かれるのはパッケージからインストールされたプログラムの場合だけで、それ以外の自作のプログラムはコアダンプだけがカレントディレクトリに作成されます。
ではパッケージからのインストールかどうかはどういう判断をしているのでしょう。ソースを見ますと、パッケージに所属するかどうかは厳密なチェックはしておらず下記のディレクトリ配下にあるかどうかだけを見ています。具体的にはコマンドの絶対パスが下記の文字で始まっているかどうかをチェックしています。
但し '/var/lib/', '/usr/local/'
で始まるものは除外(パッケージ所属で無いと判断)します。
'/bin/', '/boot', '/etc/', '/initrd', '/lib', '/sbin/', '/opt', '/usr/', '/var'
更にコードを見ますとユーザホームに下記の設定ファイルを作成しておくと上記に該当しないプログラムであってもパッケージ所属プログラムと同様に扱うように設定する事が可能でした。これは下記の内容で作成します。
$ cat ~/.config/apport/settings [main] unpackaged=true $
これによって自作の物であってもカレントディレクトリと /var/crash の両方にコアファイルが作成されるようになります。設定ファイルが無い場合は unpackaged=false と同じ扱いになります。それでは確認してみましょう。
$ ls -l . /var/crash .: total 368 -rw------- 1 ubuntu ubuntu 245760 May 25 10:37 core -rw------- 1 ubuntu ubuntu 245760 May 25 06:00 core.1507.1507.1621922456 -rwxrwxr-x 1 ubuntu ubuntu 17472 May 24 02:55 segf -rw-rw-r-- 1 ubuntu ubuntu 63 May 24 02:55 segf.c /var/crash: total 24 -rw-r----- 1 ubuntu whoopsie 24573 May 25 10:37 _home_ubuntu_tests_segf.1000.crash $
ログには下記の情報が出力されていました。
$ tail -f /var/log/apport.log ... ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: called for pid 4856, signal 11, core limit 18446744073709551615, dump mode 1 ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: ignoring implausibly big core limit, treating as unlimited ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: executable: /home/ubuntu/tests/segf (command line "./segf") ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: debug: session gdbus call: (true,) ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: wrote report /var/crash/_home_ubuntu_tests_segf.1000.crash ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: writing core dump to core (limit: -1) ERROR: apport (pid 4857) Tue May 25 10:37:50 2021: writing core dump core of size 245760
/var/crash には _home_ubuntu_tests_segf.1000.crash
と言う名前で作成されています。ソースを見ますと /var/crash 下に作られるレポート名は上述の /proc/sys/kernel/core_pattern の設定で渡されるパラメータに関わらず下記の書式で作成されています。
'%s/%s.%i.crash' % (apport.fileutils.report_dir, info['ExecutablePath'].replace('/', '_'), pidstat.st_uid)
項目 | 意味 |
---|---|
apport.fileutils.report_dir | '/var/crash' |
info['ExecutablePath'] | コマンドの絶対パス |
pidstat.st_uid | ユーザID |
一方カレントに作成されるファイル名は core
となっています。
この書式がどうなっているか見てみますと、こちらも固定のようです。
但し /proc/sys/kernel/core_uses_pid
をチェックしており、この値が 0 で無ければ core.{pid}
の書式で作成されるようです。
確認してみました。ログから core.4885 が作成されている事が分かります。
ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: called for pid 4885, signal 11, core limit 18446744073709551615, dump mode 1 ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: ignoring implausibly big core limit, treating as unlimited ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: executable: /home/ubuntu/tests/segf (command line "./segf") ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: debug: session gdbus call: (true,) ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: wrote report /var/crash/_home_ubuntu_tests_segf.1000.crash ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: writing core dump to core.4885 (limit: -1) ERROR: apport (pid 4886) Tue May 25 10:46:32 2021: writing core dump core.4885 of size 245760 $ ls -l total 608 -rw------- 1 ubuntu ubuntu 245760 May 25 10:37 core -rw------- 1 ubuntu ubuntu 245760 May 25 06:00 core.1507.1507.1621922456 -rw------- 1 ubuntu ubuntu 245760 May 25 10:46 core.4885 -rwxrwxr-x 1 ubuntu ubuntu 17472 May 24 02:55 segf -rw-rw-r-- 1 ubuntu ubuntu 63 May 24 02:55 segf.c ... $
レポート及びコアファイルは下記の条件でも作成するかどうかの判断をしています。
- 受信したシグナルが
SIGXCPU, SIGXFSZ
の場合カレントにだけコアファイルを作成します。 /etc/apport/
の下にblacklist.d, whitelist.d
と言うディレクトリがあります 該当のコマンドが /etc/apport/blacklist.d 下のファイルに登録されていた場合は作成しません。 反対に /etc/apport/whitelist.d 下のファイルに登録されていない場合、作成しません。blacklist.d, whitelist.d 下のファイルは両方とも対象とするプログラムの絶対パスが書かれた テキストファイルです。
$ cat /etc/apport/blacklist.d/thunderbird /usr/lib/thunderbird/thunderbird /usr/lib/thunderbird/plugin-container $
- 更にユーザホームに
~/.apport-ignore.xml
があればチェックされます。リストに登録されており、項目の登録時刻 >= 障害発生時刻
ならば作成しません。こちらは参考にする情報が無かったのですが下記のような書式と思われます。
<?xml version="1.0" ?> <apport> <ignore mtime="nnnn" program="program-path"/> ... </apport>
- ユーザセッションが閉じた事により発生した場合は作成しません。
- systemd の監視にかかった場合は作成しません。
- プログラムの実行ユーザ、グループID と所有ユーザ、グループIDが異なる場合はレポートだけが作成されます。
まとめますと下記のようになります。
チェック条件 | レポート作成有無 | コアファイル作成有無 | メッセージ |
---|---|---|---|
SIGXCPU, SIGXFSZ 受信 | × | ○ | Ignoring signal %s (caused by exceeding soft RLIMIT) |
ブラックリストに登録 | × | × | executable version is blacklisted, ignoring |
ホワイトリストに未登録 | × | × | executable version is blacklisted, ignoring |
ユーザのブラックリストに登録 | × | × | executable version is blacklisted, ignoring |
ユーザセッションのクローズ | × | × | happens for shutting down session, ignoring |
systemd の監視 | × | × | Ignoring systemd watchdog restart |
実行ユーザ、グループIDと所有ユーザ、グループIDが異なる | ○ | × | disabling core dump for suid/sgid/unreadable executable |
- ○:作成する ×:作成しない
- 表の最後の項目は条件に該当した場合に出力するメッセージです。
上記条件を満たすプログラム | レポート作成有無 | コアファイル作成有無 |
---|---|---|
パッケージプログラム | ○ | ○ |
パッケージ外プログラム |
× | ○ |
パッケージ外プログラム |
○ | ○ |
- ○:作成する ×:作成しない
- レポート、コアフィル作成時には下記のメッセージが出力されます。
- レポート作成時メッセージ:wrote report xxxx
- コアファイル作成時メッセージ:writing core dump to xxx (limit: nn)
またカレントに作成されるコアファイルは上書きされません。
/var/crash 下のレポートはそれが送信済みの場合は上書きされます。レポートのチェックは該当ファイルに python os.stat を使って得られる stat 情報の st_atime, st_mtime 属性が st_atime > st_mtime
の場合、送信済みと判断します。
ところで /var/rcrash に作られるファイルですがお察しの通り、これはコアファイルそのものではありません。その為 gdb にそのまま食わせてもエラーになります。
レポートは Debian のレポート形式に倣って作成されているとの事です。
レポートファイルの内容は以下のようにテキストファイルになります。
$ file /var/crash/_home_ubuntu_tests_segf.1000.crash /var/crash/_home_ubuntu_tests_segf.1000.crash: ASCII text, with very long lines $ head -n 101 /var/crash/_home_ubuntu_tests_segf.1000.crash ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Tue May 25 10:46:32 2021 DistroRelease: Ubuntu 20.04 ExecutablePath: /home/ubuntu/tests/segf ExecutableTimestamp: 1621824915 ProcCmdline: ./segf ProcCwd: /home/ubuntu/tests ProcEnviron: SHELL=/bin/bash LANG=en_US.UTF-8 TERM=kterm XDG_RUNTIME_DIR=<set> PATH=(custom, no user) ProcMaps: 5564b2bc7000-5564b2bc8000 r--p 00000000 fc:02 7678 /home/ubuntu/tests/segf 5564b2bc8000-5564b2bc9000 r-xp 00001000 fc:02 7678 /home/ubuntu/tests/segf ... Uname: Linux 5.4.0-73-generic x86_64 UserGroups: adm cdrom dip lxd plugdev sudo _LogindSession: 4 CoreDump: base64 H4sICAAAAAAC/0NvcmVEdW1wAA== 7X0JYFTV9f6bLBAUQqwgIIuDIiJqNiKEYHACCUxsgEi ...
このレポートファイルは apport-unpack
コマンドを使って展開できます。上記ファイルを展開してみます。
下記で exp は展開先の任意のディレクトリ名です。無ければ作成されます。
$ apport-unpack /va/r/crash/_home_ubuntu_tests_segf.1000.crash exp $ ls exp/ Architecture DistroRelease _LogindSession ProcCwd ProcStatus UserGroups CoreDump ExecutablePath ProblemType ProcEnviron Signal Date ExecutableTimestamp ProcCmdline ProcMaps Uname $
個々の情報については言及しませんが名前から凡そ想像が付くのではないでしょうか。CoreDump と言うファイルがコアファイルになります。
$ file exp/CoreDump exp/CoreDump: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './segf', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: './segf', platform: 'x86_64' $
ExecutablePath はコマンドの絶対パス、Signal は受信したシグナルIDです。
$ cat exp/ExecutablePath
/home/ubuntu/tests/segf
$ cat exp/Signal
11
$
自作のアプリでシステムのバグが発生した場合などにはこれを使って報告すれば良さそうです。またパッケージでインストールされたプログラムのダンプもここで参照できるのでこれを使って自分でも調べられそうです。
試しに bash を使って確認してみましょう。
$ bash -c 'kill -SEGV $$' Segmentation fault (core dumped) $ ls /var/crash _home_ubuntu_tests_segf.1000.crash _usr_bin_bash.1000.crash $
ファイルが出来ましたので展開して gdb で見てみましょう
$ apport-unpack /var/crash/_usr_bin_bash.1000.crash exp.bash $ gdb /usr/bin/bash exp.bash/CoreDump GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... No symbol table is loaded. Use the "file" command. Breakpoint 1 (ptmalloc_init) pending. Reading symbols from /usr/bin/bash... (No debugging symbols found in /usr/bin/bash) [New LWP 12941] Core was generated by `bash'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8aa8a1955b in kill () at ../sysdeps/unix/syscall-template.S:78 78 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) q $
上記のように通常インストールされたバイナリではデバッグ情報がストリップされているのでデバッグ情報が読み込めず、このままでは十分なデバッグは出来ません。しかし Ubuntu ではデバッグ情報をインストールするパッケージが提供されているのでそれを利用する事が出来ます。それには新たにデバッグ情報パッケージ用のアプトラインを追加します。
$ cat /etc/apt/sources.list.d/ddebs.list deb http://ddebs.ubuntu.com focal main restricted universe multiverse deb http://ddebs.ubuntu.com focal-updates main restricted universe multiverse deb http://ddebs.ubuntu.com focal-proposed main restricted universe multiverse $ wget http://ddebs.ubuntu.com/dbgsym-release-key.asc $ sudo apt-key add dbgsym-release-key.asc OK $ sudo apt update $
該当コマンドのデバッグ情報用のパッケージ名はそれが {PackageName} に所属するとすれば {PackageName}-dbgsym
になります。bash の場合 bash-dbgsym となります。
$ sudo apt install -y bash-dbgsym $ dpkg -L bash-dbgsym /. /usr /usr/lib /usr/lib/debug /usr/lib/debug/.build-id /usr/lib/debug/.build-id/a6 /usr/lib/debug/.build-id/a6/cb40078351e05121d46daa768e271846d5cc54.debug /usr/lib/debug/.build-id/ef /usr/lib/debug/.build-id/ef/39c663826a06326caeece0440aefb6f59f124b.debug /usr/share /usr/share/doc /usr/share/doc/bash-dbgsym $
これで準備が整いましたので再度、見てみましょう。
$ gdb /usr/bin/bash exp.bash/CoreDump GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... No symbol table is loaded. Use the "file" command. Breakpoint 1 (ptmalloc_init) pending. Reading symbols from /usr/bin/bash... Reading symbols from /usr/lib/debug/.build-id/a6/cb40078351e05121d46daa768e271846d5cc54.debug... [New LWP 5657] Core was generated by `bash'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f0f78fc955b in kill () at ../sysdeps/unix/syscall-template.S:78 78 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) q $
今度は /usr/lib/debug/.build-id/a6/cb40078351e05121d46daa768e271846d5cc54.debug が読み込まれているのが分かります。
それでは障害レポートの送信の流れについても若干触れておきます。
障害レポートを監視する update-notifier
と言うアプリがあります。これはデスクトップパッケージをインストールすると依存してインストールされます。
また update-notifier パッケージは /etc/xdg/autostart/update-notifier.desktop をインストールしており、これが update-notifier を起動します。update-notifier.desktop 自体はデスクトップにログイン時、自動的に起動されます。
update-notifier は gtk_main() をコールしてループ処理しており /var/crash/ を監視しています。レポートが登録されると apport-gtk を実行しレポートがある旨を下記のように画面に表示します。
ユーザがレポートを送信する事を選択するとレポートが送信され送信したマークとして /var/crash/ に xxx.upload と言うファイルが作成されます。試しにネットワークをダウンした状態で送信してみますと確かに空の .upload ファイルが作成されておりました。
$ ls -l /var/crash/ total 132 -rw-r----- 1 ubuntu whoopsie 134316 May 26 01:40 _usr_bin_bash.1000.crash -rw-rw-r-- 1 ubuntu whoopsie 0 May 26 01:40 _usr_bin_bash.1000.upload $
送信要求は https://daisy.ubuntu.com
に送られ、もしそのレポートが未登録ならばレポート本体を転送します。レポートファイルはサイズが大きいので送信時は負荷が掛かるという書き込みを見掛けましたので、何らかの運用中には注意が必要かも知れません。
尚 crash によるレポートの送信はデフォルトでは制限されているようです。
下記は レポートを送信する際に参照する設定ですが、デフォルトでは ubuntu
の情報が参照されるようになっています。この problem_types
と言う情報が送信対象のタイプとなっています。
前述の レポートファイルの内容 では ProblemType: Crash
となっているのでこのレポートは対象外となります。
送信対象とするには下記 problem_types の先頭に '#' を付与してコメントアウト(全てのタイプを対象)するか、対象タイプに 'Crash' を追加します (例えば['Bug', 'Package', 'Crash'])。
$ cat /etc/apport/crashdb.conf # map crash database names to CrashDatabase implementations and URLs default = 'ubuntu' def get_oem_project(): '''Determine OEM project name from Distribution Channel Descriptor Return None if it cannot be determined or does not exist. ''' try: dcd = open('/var/lib/ubuntu_dist_channel').read() if dcd.startswith('canonical-oem-'): return dcd.split('-')[2] except IOError: return None databases = { 'ubuntu': { 'impl': 'launchpad', 'bug_pattern_url': 'http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml', 'dupdb_url': 'http://people.canonical.com/~ubuntu-archive/apport-duplicates', 'distro': 'ubuntu', 'problem_types': ['Bug', 'Package'], 'escalation_tag': 'bugpattern-needed', 'escalated_tag': 'bugpattern-written', }, 'canonical-oem': { 'impl': 'launchpad', 'bug_pattern_url': 'http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml', 'project': get_oem_project(), }, 'debug': { # for debugging 'impl': 'memory', 'bug_pattern_url': '/tmp/bugpatterns.xml', 'distro': 'debug' }, } $
レポートの送信に関しては無用なレポートを送ると迷惑になるので実際には試しておりませんが Ubuntu サイトの情報や関連のあるソースを参考に凡その動きを記しました。興味のある人は ErrorTracker が参考になります。
調べた結果
以上で調べた内容は終わりですが、冒頭で述べた、コアファイルの書式については結局 apport の管理下では自由な名前を付ける事が出来ない事が分かりました。任意の書式を使いたい場合は素直に /proc/sys/kernel/core_pattern を修正するしか無さそうです。
また本内容は上述の Ubuntu 20.04 で確認しております。バージョンによっては動作が異なるかも知れませんので留意ください。
手元の環境で 16.04、18.04 の core_pattern だけですが確認しますと 20.04 とは異なっておりました。
$ lsb_release -a | grep Release No LSB modules are available. Release: 16.04 $ cat /proc/sys/kernel/core_pattern |/usr/share/apport/apport %p %s %c %P $
$ lsb_release -a | grep Release No LSB modules are available. Release: 18.04 $ cat /proc/sys/kernel/core_pattern |/usr/share/apport/apport %p %s %c %d %P $
尚 apport は今まで結構多くの 脆弱性が報告されておりますので参考までにリストしておきます。