Apport ~Ubuntu のコアダンプ作成動作~

執筆者:角馬 文彦


調べたキッカケ

先日コアダンプファイルを見ようとして気付いた事があるのでお話しようと思います。
今回の内容は下記の環境で確認しています。

$ 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: 20200619083602秒
Group       : System Environment/Libraries
Size        : 353045
License     : GPLv2+
Signature   : RSA/SHA256, 20200404054817秒, Key ID 24c6a8a7f4a80eb5
Source RPM  : abrt-2.1.11-57.el7.centos.src.rpm
Build Date  : 20200403005842秒
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
  1. ○:作成する ×:作成しない
  2. 表の最後の項目は条件に該当した場合に出力するメッセージです。
プログラムによるファイル作成有無
上記条件を満たすプログラム レポート作成有無 コアファイル作成有無
パッケージプログラム
パッケージ外プログラム
  • 設定が unpackaged=false
  • 設定ファイル無し
  • ×
    パッケージ外プログラム
  • 設定が unpackaged=true
    1. ○:作成する ×:作成しない
    2. レポート、コアフィル作成時には下記のメッセージが出力されます。
      • レポート作成時メッセージ: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 を実行しレポートがある旨を下記のように画面に表示します。

    f:id:kak-va:20210527114453p:plain
    障害通知

    ユーザがレポートを送信する事を選択するとレポートが送信され送信したマークとして /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 は今まで結構多くの 脆弱性が報告されておりますので参考までにリストしておきます。