2018の7日目です。まで、開発中以外のタイミングでクラッシュするプロセスのcoreを取得するのはなかなか大変でした。デフォルトではプロセスのCWDにcoreファイルを保存しますが、このサイズや個数を制御する標準的な方法がなかったため、「ときどきクラッシュするシステム」の問題を解析するためにcore出力を有効にすると、ファイルシステムがあふれてしまう懸念があったのです。betaではsystemd-coredumpがデフォルトで有効になっています。systemd-coredumpはプロセス異常終了時に出力されるcoreファイルを管理する仕組みで、以下のような機能を提供します。以下の個別のファイルに保存します。RHELではjournal内に保存するのではなくファイルでの保存がデフォルトです。unit、タイムスタンプ、ユーザ等さらに可能であればcoreファイル取得と同時にバックトレースを取得あらかじめ決めた基準で過去のcoreファイルを削除するこの仕組みが導入されたことで、長期運用中にcoreファイル出力を有効にすることが(相応のI/Oなどは発生しますが)現実的になってきます。systemd-coredumpが有効な環境でのcoreファイルの扱いについて見ていきましょう。設定してcore出力を有効にしたのち、適当なプログラムを作成して、わざとSEGVを発生させます。ようにして「1日前以降」のようなフィルタ指定を行うことで絞り込みます。ように実行ファイルでも絞り込めます。出力冒頭のHint:という行は、メタデータはsystemd-journalに保存されているため一般ユーザはシステム全体のcoreについての情報は見えないことについての警告です。システム全体のcoreを見たい場合には、ユーザをsystemd-journalグループに入れるかroot権限でcoredumpctlを実行しましょう。コマンドで確認できます。/usr/bin/xfs_spaceman)、journalctlでも使う検索などで出力対象を絞りこめます。ソフトウェアの開発中には直前に出力されたcoreを指定する「-1」オプションが役に立つでしょう。実はこの情報以外にもprocfsで取得できる各種の情報がjournalに保存されています。ようにすると確認できるので気になる人は見てみましょう。ように実行することで簡単にgdbを実行できます。dereferenceなのでこれはSEGVも起きるというものですね。このファイルがcoreファイルです。lz4圧縮されているので通常のcoreファイルよりだいぶ小さくなります。coreファイルはrootユーザ、rootグループで保存されていますが、ACLで該当userにread権限が付与されています。ようにすると保存されている場所やファイル名を考えずにファイルへ出力できます。rest.coredumpが消されるのはどういうタイミングか?systemd-coredump環境では、coreファイルは以下の基準で削除されます。3日)以上アクセスなしはじめの2つは、systemd-coredumpがcoreを保存する直前と直後にcoredump.conf設定中のMaxUseとKeepFreeを反映して削除をおこないます。容量の制限を満たすまで古いものから順に削除されます。今出力したばかりのcoreファイルは維持されます。systemd-tmpfilesを利用して削除をおこないます。3dと指定されており、このディレクトリの中にある3日以上アクセスがないファイルはsystemd-tmpfiles-cleanが削除します。前述のとおりcoredumpのメタデータはsystemd-journalのログに保存されています。RHEL8betaのデフォルトではsystemd-journalのログが永続化されておらず、coreファイルは残りますがメタデータが失われてしまいます。ディレクトリを作成してjournalの永続化を行うのがおすすめです。journalが消えてしまっても、systemd-coredumpが保存するcoreファイルには拡張属性を利用していくつかのメタデータが添付されています。以下はgetfattrでメタデータを確認する例です。core.packagekitd.0.811279367f5541c294300e7ec3c33223.23641.1543801829000000.lz4user.coredump.comm="packagekitd"user.coredump.exe="/usr/libexec/packagekitd"user.coredump.gid="0"user.coredump.hostname="snake.usersys.redhat.com"user.coredump.pid="23641"user.coredump.rlimit="18446744073709551615"user.coredump.signal="11"user.coredump.timestamp="1543801829"user.coredump.uid="0"systemd-coredumpのデフォルトでは利用メモリ量が2GBまでのプロセスを対象として、最大2GBのcoreファイルを作成する設定になっています。ExternalSizeMax)を変更しましょう。アプリケーションがcoreファイルの出力先を指定できる(CWDを指定されたディレクトリに変更する)場合にも、systemd-coredumpの仕組みが優先されます。mountなどで対応します。CephFSの脅威まいど。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。