2011-10-11 121 views
42

每到這時,我的應用程序崩潰不會產生一個核心轉儲文件。我記得前幾天,在另一臺服務器上它生成的。我正在使用屏幕上的應用程序在bash這樣的:核心轉儲文件不產生

#!/bin/bash 
ulimit -c unlimited 
while true; do ./server; done 

正如你可以看到我使用ulimit -c unlimited如果我要生成一個核心轉儲這是非常重要的,但它仍然沒有產生它,當我遇到分段錯誤時。 我該如何使它工作?

+1

它不看的情況下,但如果你使用'sudo'要小心(可能還有其他類型的子殼):在'ulimit -c unlimited; sudo ./server-crashing',當服務器崩潰崩潰時,新的限制將不起作用。 – ribamar

回答

40

確保您的當前目錄(在崩潰時 - server可能會更改目錄)是可寫的。如果服務器調用setuid,則該目錄必須可由該用戶寫入。

另請檢查/proc/sys/kernel/core_pattern。這可能核心轉儲重定向到另一個目錄,並目錄必須是可寫的。更多信息here

+13

是的,core_pattern比較棘手。當Arch Linux切換到systemd時,我遇到了這個問題。現在,我使用'回聲「核心」>的/ proc/sys目錄/內核/ core_pattern'讓我的核心轉儲預期(默認情況下它被寫入到systemd期刊)。你可以花費很多時間來弄清楚...... –

+0

@PhilippClaßen:我需要。這也是我所做的。搞清楚如何做到這一點,我猜是另一種方式太難了。我試過了,但是我做不到。 –

+1

作爲一個側面說明,該信息在'man 5 core'手冊頁中。該模式支持'%p'和其他這樣的標誌。 –

1

此外,請檢查以確保您有足夠的磁盤空間在/var/core或核心轉儲寫入的任何位置。如果分區是almos full或100%的磁盤使用率,那就是問題所在。我的核心轉儲平均有幾個演出,所以你應該確保分區上至少有5-10個演出。

43

This link包含爲什麼沒有產生核心轉儲一個很好的清單:

  • 核心會比目前的上限。
  • 您沒有轉儲核心(目錄和文件)所需的權限。請注意,核心轉儲放置在轉儲過程的當前目錄中,該目錄可能與父進程不同。
  • 驗證文件系統是可寫的,並有足夠的可用空間。
  • 如果在工作目錄中存在名爲core的子目錄,則不會轉儲核心。
  • 如果名爲core的文件已經存在但有多個硬鏈接,則內核將不會轉儲核心。
  • 驗證可執行文件的權限,如果可執行文件啓用了suid或sgid位,默認情況下將禁用核心轉儲。如果您擁有執行權限但文件沒有讀取權限,情況也是如此。
  • 驗證該過程是否未更改工作目錄,核心大小限制或可抽出標誌。
  • 某些內核版本無法轉儲具有共享地址空間(AKA線程)的進程。較新的內核版本可以轉儲這些進程,但會將pid附加到文件名。
  • 可執行文件可能是不支持核心轉儲的非標準格式。每個可執行格式必須實現一個核心轉儲例程。
  • 分段錯誤實際上可能是內核Oops,請檢查系統日誌是否有任何Oops消息。
  • 應用程序名爲exit()而不是使用核心轉儲處理程序。
+3

另外:如果應用程序將信號處理程序'SIGSEGV',則沒有進一步的技巧(見http://stackoverflow.com/questions/16697361)核心轉儲不會被創建。 – FooF

+4

有一點需要補充:當一個程序調用'setuid()'例如要刪除root權限,它不再是核心可丟棄的(可執行文件不必是suid)。使用默認的Arch Linux配置測試Linux 3.12。我不知道爲什麼會發生這種情況,它不在任何地方。在'setuid'修復這個之後調用'prctl(PR_SET_DUMPABLE,1,...)',所以它不是文件系統權限問題。 – regnarg

+2

實際上,這在prctl手冊頁上的PR_SET_DUMPABLE部分中進行了說明:http://man7.org/linux/man-pages/man2/prctl.2.html – hdiogenes

4

檢查:

$ sysctl kernel.core_pattern 

,看看如何創建您的轉儲(%E會的進程名,並%T將系統時間)。

如果您已經使用Ubuntu,您的轉儲文件是由apport/var/crash中創建的,但格式不同(編輯文件以查看它)。

您可以通過測試:

sleep 10 & 
killall -SIGSEGV sleep 

如果核心傾銷成功,你會看到後分段故障指示「(核心轉儲)」。

瞭解更多:

How to generate core dump file in Ubuntu


Ubuntu的

請閱讀更多:

https://wiki.ubuntu.com/Apport

0

雖然這不是去對於問這個問題的人來說是一個問題,因爲他們使用ulimit命令運行了用腳本生成核心文件的程序,我想記錄下ulimit命令是特定於shell的,其中你運行它(像環境變量)。我花了太多時間在一個shell中運行ulimit和sysctl和東西,以及我想要在另一個shell中轉儲核心的命令,並想知道爲什麼不生成核心文件。

我會將它添加到我的bashrc中。 sysctl一旦發佈就適用於所有進程,但ulimit只適用於發佈它的shell(也可能是後代) - 但不適用於正在運行的其他shell。

0

注意:如果您自己編寫了任何崩潰處理程序,那麼核心可能不會生成。因此,尋找線上的東西的代碼:

signal(SIGSEGV, <handler>); 

所以SIGSEGV將由處理程序處理,你不會得到核心轉儲。

2

注意,如果您從服務啓動服務器,這樣的ulimit不會有效那裏將啓動不同的bash命令。嘗試把這個腳本本身

ulimit -c unlimited 
1

這裏給出的答案包括相當不錯,其核心轉儲不創建大多數情況下。但是,在我的例子中,這些都沒有應用。我發佈這個答案作爲其他答案的補充。

如果你的核心文件沒有被創建出於任何原因,我建議查看/ var/log/messages。這裏可能會提示爲什麼不創建核心文件。在我的情況有一條線,說明根本原因:

Executable '/path/to/executable' doesn't belong to any package 

要「不」解決此問題編輯/etc/abrt/abrt-action-save-package-data.conf並更改ProcessUnpackaged爲'是'。

ProcessUnpackaged = yes 

此設置指定是否爲未與軟件包管理器一起安裝的二進制文件創建核心。

0

如果您調用daemon()然後守護進程,默認情況下當前工作目錄將更改爲/。所以,如果你的程序是一個守護進程,那麼你應該在/目錄中尋找一個核心,而不是在二進制文件的目錄。

1

如果一個人是一個Linux發行版(例如CentOS的,Debian的),那麼也許是最方便的方式,以瞭解核心文件和相關條件的man page。只是從終端運行下面​​的命令:

man 5 core 
2

對於記錄,在Debian 9拉伸(systemd),我必須安裝包systemd-coredump。之後,在文件夾/var/lib/systemd/coredump中生成核心轉儲文件。

此外,這些核心轉儲是在lz4格式壓縮。要解壓縮,您可以使用包liblz4-tool這樣的:lz4 -d FILE

爲了能夠調試使用gdb解壓縮內核轉儲,我也只好到完全長文件名命名弄成短...