web-dev-qa-db-ja.com

systemdを備えたUbuntuサーバー-バックトレースまたはコアダンプを取得する方法？

私はsystemdでUbuntu 18.04サーバーを使用しています。最近、私の部門が開発したプログラムは、次のエラーで1日に2回クラッシュしました。

Jun 07 06:33:07 xxx systemd[1]: xxx.service: Main process exited, code=killed, status=11/SEGV
Jun 07 06:33:07 xxx systemd[1]: xxx.service: Failed with result 'signal'.

次のステップは、バックトレースまたはコアダンプを取得することですが、systemdを使用してUbuntuサーバーでこれを行う方法はわかりません。

systemd-coredump、coredumpctl、またはその他のユーティリティを使用して追求する必要があるかどうかわかりません。

また、どのコマンドを発行するかわかりません。上記のユーティリティには、さまざまな機能などに関するドキュメントがたくさんありますが、次のような簡潔な例は見つかりません。

Sudo apt-get install xyz

(run x, y, z commands to get core dump)

誰もがこれをうまく説明する簡潔な例やチュートリアルWebサイトを提供できますか？さまざまな手の込んだ機能を使用する必要はありません。基本的なコアダンプを取得しようとしています。

systemdubuntu-18.04debugging
4
cdahms

たとえば、比較的単純なサービスであるchrony NTPデーモンです。

dbgsymパッケージでデバッグシンボルをインストールします。 残念ながら、デフォルトではddebsリポジトリはソースファイルにありません。また、パッケージを見つけるための優れたスクリプトがないため、パッケージ名に-dbgsymを追加することから始めます。

Sudo apt install chrony-dbgsym

おそらく、最新のLinuxサーバーでコアダンプを処理する方法について考える必要があります そして、その場合、コアダンプファイルだけに戻ることを検討しています。個人的には、サーバーのapportから何も役に立たないのですが、coredumpctlが役立つと思います。したがって、Ubuntu 18.04でのsystemdアプローチ：

Sudo systemctl stop apport
Sudo systemctl mask --now apport
Sudo apt install systemd-coredump
# Verify this changed the core pattern to a pipe to systemd-coredump
sysctl kernel.core_pattern

# Reproduce the crash.
Sudo killall -s SIGSEGV chronyd

# List collected dumps.
coredumpctl

# Invoke debugger on the latest one.
Sudo coredumpctl gdb
# systemd >= 239  the gdb verb was renamed debug. Also, select core by PID.
Sudo coredumpctl debug 5809

# In GDB, the basic thing to get is a stack trace. Ask the developer what else they want.
(gdb) thread apply all bt

デバッガセッションの開始は次のようになります。

John@coredump:~$ coredumpctl
TIME                            PID   UID   GID SIG COREFILE  EXE
Sat 2019-06-08 12:55:16 UTC    5809   111   115  11 error     /usr/sbin/chronyd
John@coredump:~$ Sudo coredumpctl gdb
           PID: 5809 (chronyd)
           UID: 111 (_chrony)
           GID: 115 (_chrony)
        Signal: 11 (SEGV)
     Timestamp: Sat 2019-06-08 12:55:16 UTC (1h 19min ago)
  Command Line: /usr/sbin/chronyd
    Executable: /usr/sbin/chronyd
 Control Group: /system.slice/chrony.service
          Unit: chrony.service
         Slice: system.slice
       Boot ID: c9a0a69a73d245c1ae5dfe7d491ead0a
    Machine ID: d2934a6e67f81ae0097be31003da0b31
      Hostname: coredump
       Storage: /var/lib/systemd/coredump/core.chronyd.111.c9a0a69a73d245c1ae5dfe7d491ead0a.5809.1559998516000000.lz4
       Message: Process 5809 (chronyd) of user 111 dumped core.

                Stack trace of thread 5809:
                #0  0x00007eff1ce1403f __GI___select (libc.so.6)
                #1  0x00005597867eb3be n/a (chronyd)
                #2  0x00005597867e1071 n/a (chronyd)
                #3  0x00007eff1cd1eb97 __libc_start_main (libc.so.6)
                #4  0x00005597867e127a n/a (chronyd)

GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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"...
Reading symbols from /usr/sbin/chronyd...Reading symbols from /usr/lib/debug/.build-id/89/dcd398c87777f4c869bfd0831215eeb8b6c7fe.debug...done.
done.
[New LWP 5809]
[Thread debugging using libthread_db enabled]
Using Host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/chronyd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007eff1ce1403f in __GI___select (nfds=4, readfds=readfds@entry=0x7ffc0fd73c80,
    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7ffc0fd73be0)
    at ../sysdeps/unix/sysv/linux/select.c:41
41      ../sysdeps/unix/sysv/linux/select.c: No such file or directory.
(gdb) thread apply all bt

Thread 1 (Thread 0x7eff1df14740 (LWP 5809)):
#0  0x00007eff1ce1403f in __GI___select (nfds=4, readfds=readfds@entry=0x7ffc0fd73c80,
    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7ffc0fd73be0)
    at ../sysdeps/unix/sysv/linux/select.c:41
#1  0x00005597867eb3be in SCH_MainLoop () at sched.c:747
#2  0x00005597867e1071 in main (argc=<optimized out>, argv=0x7ffc0fd73fb8) at main.c:605

この不自然な例では、I/Oを待機しているタスクに無礼にシグナルを送信したため、select（）でキャッチしました。

より複雑なソフトウェアにはおそらく他のシンボルが不足しているので、それらをインストールし、ソースコードをインストールして、デバッグを続行します。

5
John Mahowald