コアダンプファイルは生成されません
アプリケーションがクラッシュするたびに、コアダンプファイルが生成されません。数日前、別のサーバーでwasが生成されたことを覚えています。私は次のようにbashの画面を使用してアプリを実行しています：
#!/bin/bash
ulimit -c unlimited
while true; do ./server; done
ご覧のとおり、私はulimit -c unlimitedこれはコアダンプを生成する場合に重要ですが、セグメンテーションフォールトが発生した場合でも生成されません。どうすればそれを機能させることができますか？
現在のディレクトリ（クラッシュ時-serverはディレクトリを変更する可能性があります）が書き込み可能であることを確認してください。サーバーがsetuidを呼び出す場合、ディレクトリはそのユーザーが書き込み可能である必要があります。
また、/proc/sys/kernel/core_pattern。それはコアダンプを別のディレクトリにリダイレクトする可能性があり、thatディレクトリは書き込み可能でなければなりません。詳細 こちら 。
このリンク には、コアダンプが生成されない理由の良いチェックリストが含まれています。
- コアは現在の制限よりも大きかったでしょう。
- コア（ディレクトリとファイル）をダンプするために必要な権限がありません。コアダンプは、ダンププロセスの現在のディレクトリに配置され、親プロセスとは異なる場合があることに注意してください。
- ファイルシステムが書き込み可能で、十分な空き領域があることを確認します。
- Coreという名前のサブディレクトリが作業ディレクトリに存在する場合、コアはダンプされません。
- Coreという名前のファイルが既に存在するが、複数のハードリンクがある場合、カーネルはコアをダンプしません。
- 実行可能ファイルのsuidまたはsgidビットが有効になっている場合、実行可能ファイルのアクセス許可を確認します。コアダンプはデフォルトで無効になります。ファイルに対する実行権限はあるが読み取り権限はない場合も同様です。
- プロセスが作業ディレクトリ、コアサイズ制限、またはダンプ可能フラグを変更していないことを確認します。
- 一部のカーネルバージョンは、共有アドレススペース（別名スレッド）を持つプロセスをダンプできません。新しいカーネルバージョンでは、このようなプロセスをダンプできますが、pidをファイル名に追加します。
- 実行可能ファイルは、コアダンプをサポートしない非標準形式である可能性があります。各実行可能形式は、コアダンプルーチンを実装する必要があります。
- セグメンテーションフォールトは実際にはカーネルOopsである可能性があります。システムログでOopsメッセージが発生していないか確認してください。
- アプリケーションは、コアダンプハンドラーを使用する代わりに
exit()を呼び出しました。
サービスからのサーバーを開始する場合、別のbashセッションが開始されるため、そこでulimitが有効にならないことに注意してください。これをスクリプト自体に入れてみてください：
ulimit -c unlimited
小切手：
$ sysctl kernel.core_pattern
ダンプの作成方法を確認します（％eはプロセス名、％tはシステム時刻になります）。
Ubuntuを使用している場合、ダンプは/var/crashのapportによって作成されますが、形式は異なります（ファイルを編集して表示します）。
次の方法でテストできます。
sleep 10 &
killall -SIGSEGV sleep
コアダンプが成功した場合、セグメンテーションエラー表示の後に「（core dumped）」が表示されます。
続きを読む：
Ubuntu
でもっと読んでください：
記録のために、Debian 9 Stretch（systemd）では、パッケージsystemd-coredumpをインストールする必要がありました。その後、フォルダー/var/lib/systemd/coredumpにコアダンプが生成されました。
さらに、これらのコアダンプはlz4形式で圧縮されています。解凍するには、liblz4-toolのようなパッケージlz4 -d FILEを使用できます。
gdbを使用して圧縮解除されたコアダンプをデバッグできるようにするには、完全に長いファイル名を短い名前に変更する必要もありました...
ここで与えられた答えは、コアダンプが作成されないほとんどのシナリオをカバーしています。ただし、私の例では、これらのいずれも適用されませんでした。この回答は、他の回答への追加として投稿しています。
何らかの理由でコアファイルが作成されていない場合は、/ var/log/messagesを確認することをお勧めします。コアファイルが作成されない理由についてのヒントがあるかもしれません。私の場合、根本原因を説明する行がありました：
Executable '/path/to/executable' doesn't belong to any package
この問題を回避するには、/ etc/abrt/abrt-action-save-package-data.confを編集し、ProcessUnpackagedを「no」から「yes」に変更します。
ProcessUnpackaged = yes
この設定は、パッケージマネージャーでインストールされていないバイナリのコアを作成するかどうかを指定します。
また、/var/coreまたはコアダンプが書き込まれる場所に十分なディスク領域があることを確認してください。パーティションがいっぱいかディスク使用率が100％である場合、それが問題になります。私のコアダンプは平均して数ギガなので、パーティションで少なくとも5〜10ギガを使用できるようにする必要があります。
daemon（） を呼び出してからプロセスをデーモン化すると、デフォルトで現在の作業ディレクトリが/に変更されます。したがって、プログラムがデーモンの場合は、バイナリのディレクトリではなく、/ディレクトリでコアを探す必要があります。
Linuxディストリビューション（CentOS、Debianなど）を使用している場合、おそらくコアファイルと関連する条件について調べる最もアクセスしやすい方法はmanページにあります。ターミナルから次のコマンドを実行するだけです。
man 5 core
これは質問をした人にとっては問題にはなりませんが、ulimitコマンドを使用してスクリプトでコアファイルを生成するプログラムを実行したため、ulimitコマンドが特定のものであることを文書化したいと思います。実行するシェル（環境変数など）に。 1つのシェルでulimitとsysctlなどを実行し、もう1つのシェルでコアをダンプしたいコマンドを実行し、コアファイルが生成されなかった理由を疑問視しました。
これをbashrcに追加します。 sysctlは一度発行されるとすべてのプロセスで機能しますが、ulimitはそれが発行されたシェル（子孫も含む）でのみ機能します-実行中の他のシェルでは機能しません。
他の誰かがこれにつまずいた場合に備えて。私は他の誰かのコードを実行していました-それらがシグナルを処理していないことを確認してください。処理をコメントアウトし、コアダンプを取得しました。
注：クラッシュハンドラを自分で記述した場合、コアは生成されない可能性があります。そのため、行に何かを含むコードを検索します。
signal(SIGSEGV, <handler> );
そのため、SIGSEGVはハンドラーによって処理され、コアダンプは取得されません。
Centosで、コアファイルを生成するルートアカウントでない場合：アカウントにルート権限またはログインルートアカウントがあるように設定する必要があります。
vim /etc/security/limits.conf
accountソフトコア無制限
accountハードコア無制限
次に、securecrtまたはその他を使用してログインシェルにいる場合：
ログアウト次に再ログイン