/var/log/messages
そして、私が見ることができるように、コアを頻繁にダンプするカスタムデーモンを持つSLES 12.4 VMを使用していますcoredumpctl
。しかし、/var/lib/systemd/coredump/
他の場所ではコアファイルを見たことがありません。エラーが表示されます/var/log/messages
。
systemd-coredump[<PID>]: Failed to parse resource limit: <daemon_name>
コアサイズ制限をunlimitedに設定しました/etc/security/limits.conf
。また、アプリケーションコアダンプも有効にしました/etc/systemd/coredump.conf
。ただし、手動で実行すると、次のようになります。
[ 12.4 sles ~]# kill -SEGV <daemon PID>
コアが見つかりました/var/lib/systemd/coredump
。
/etc/security/limits.conf:
#<domain> <type> <item> <value>
#
* soft core -1
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#@student - maxlogins 4
/etc/systemd/coredump.conf:
[Coredump]
Storage=external
Compress=yes
#ProcessSizeMax=5G
#ExternalSizeMax=9G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=
/etc/sysctl.d/50-coredump.conf:
kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
限界状態:
[12.4-sles:~]# ulimit -c
unlimited
カーネル起動コアダンプのコアをどのように取得しますか?
ベストアンサー1
コンテンツが間違っているようです。/etc/sysctl.d/50-coredump.conf
とフィールドの間に追加のコンテンツが必要です。%c
%t
%e
ulimit -c
コアダンプファイルを保存するか切り捨てるか(つまり、設定を尊重するulimit -c
)決定するために、systemd-coredumpに渡すためのサポートを導入した変更でこれを確認できます。
この変更にはkernel.core_pattern
sysctlのコマンドラインを変更する必要がありますが、そのファイルの以前のバージョンがシステムに存在するようです。
これは、RPMが元のファイルを保存する必要があると思うためです(1つ/etc/sysctl.d/50-coredump.conf.rpmnew
または他の.rpm*
拡張子を見つけると手がかりを得ることができます)。
それにもかかわらず、このファイルを更新すると問題が解決します。
この問題の原因の詳細については、あなたが報告したメッセージを調べました。
systemd-coredump[<PID>]: Failed to parse resource limit: <daemon_name>
それからメッセージを見つけました。ソースツリーからしかし、コードは数字で解析できるRLIMITを受け取ることを期待しているので、そのメッセージを受信すると言ったときにフィールドを<daemon_name>
間違った順序で受信するという事実にショックを受けました。
あなたの問題を見て、50-coredump.conf
それをアップストリームツリーのツリーと比較した結果、あなたが経験している問題は、この不一致による可能性が高いという結論に急速に達しました。