怎么介绍?
分类： LINUX
2014-07-09 19:00:00
经过分析发现系统默认的core文件生成路径是/var/logs，但/var/logs目录并非系统自带的，系统初始安装默认自带的是/var/log，最终导致该系统出现core dump后并没能生成core文件，因此如何查询和修改系统默认的core dump文件生产路径呢？方法如下：
一. 查询core dump文件路径：
方法1： # cat /proc/sys/kernel/core_pattern
方法2： # /sbin/sysctl kernel.core_pattern
二. 修改core dump文件路径：
方法1：临时修改：修改/proc/sys/kernel/core_pattern文件，但/proc目录本身是动态加载的，每次系统重启都会重新加载，因此这种方法只能作为临时修改。 /proc/sys/kernel/core_pattern 例：echo ‘/var/log/%e.core.%p’ > /proc/sys/kernel/core_pattern
方法2：永久修改：使用sysctl -w name=value命令。 例：/sbin/sysctl -w kernel.core_pattern=/var/log/%e.core.%p为了更详尽的记录core dump当时的系统状态，可通过以下参数来丰富core文件的命名： %% 单个%字符
今天在Linux下调试C程序时，出现段错误，习惯性的ls下当前目录，发现没有生成core文件。惊讶了一下，怎么回事？以前都会产生的啊，难不成是程序的问题？后来同事提醒是不是系统没有打开生成core dump的设置。
还真是系统设置问题，我的ubuntu14.04是新装的，之前没有进行过core dump的相关配置，别急！我们来看看怎么对linux系统设置当程序出现段错误时产生core文件：
1、先用#ulimit -a可以查看系统core文件的大小限制（第一行），core文件大小设置为0, 即没有打开core dump设置；
-
root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
-
core file size (blocks, -c) 0
-
data seg size (kbytes, -d) unlimited
-
scheduling priority (-e) 0
-
file size (blocks, -f) unlimited
-
pending signals (-i) 46621
-
max locked memory (kbytes, -l) 64
-
max memory size (kbytes, -m) unlimited
-
open files (-n) 1024
-
pipe size (512 bytes, -p) 8
-
POSIX message queues (bytes, -q) 819200
-
real-time priority (-r) 0
-
stack size (kbytes, -s) 8192
-
cpu time (seconds, -t) unlimited
-
max user processes (-u) 46621
-
virtual memory (kbytes, -v) unlimited
-
file locks (-x) unlimited
-
2、接下来使用#ulimit -c [kbytes]可以设置系统允许生成的core文件大小；
执行#ulimit -c unlimited，然后#ulimit -a查看结果如下（第一行）：
-
root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
-
core file size (blocks, -c) unlimited
-
data seg size (kbytes, -d) unlimited
-
scheduling priority (-e) 0
-
file size (blocks, -f) unlimited
-
pending signals (-i) 46621
-
max locked memory (kbytes, -l) 64
-
max memory size (kbytes, -m) unlimited
-
open files (-n) 1024
-
pipe size (512 bytes, -p) 8
-
POSIX message queues (bytes, -q) 819200
-
real-time priority (-r) 0
-
stack size (kbytes, -s) 8192
-
cpu time (seconds, -t) unlimited
-
max user processes (-u) 46621
-
virtual memory (kbytes, -v) unlimited
-
file locks (-x) unlimited
-
此时，core dump设置打开了，再执行程序出现段错误时，在当前工作目录下产生了core文件，然后我们就可以用gdb调试core文件了。
例如：
#gdb ./test core.2065
注：Linux下的C程序常常会因为内存访问错误等原因造成segment fault(段错误)，此时如果系统core dump功能是打开的，那么将会有内存映像转储到硬盘上来，之后可以用gdb对core文件进行分析，还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。
需要说明的是：上述方法只是在当前shell中生效,重启之后，就不再有效了。永久生效的办法是如下：
永久生效办法：
#vi /etc/profile 然后，在profile中添加：
ulimit -c 1073741824
(但是，若将产生的转储文件大小大于该数字时，将不会产生转储文件)
或者
ulimit -c unlimited
这样重启机器后生效了。 或者， 使用source命令使之马上生效。
#source /etc/profile
三、指定内核转储的文件名和目录
修改完内核转储设置后，当程序core dump后发现确实在本地目录产生了core文件，但是如果程序多次core dump时，core文件会被覆盖，原因是每次core dump后生成的文件名默认都叫core，接下来就分享下如果想在每次core dum时产生的core文件都带上进程号怎么操作，或者你想把内核转储文件保存到其他目录怎么办？
1、core dump文件名自动加上进程ID
#echo 1 > /proc/sys/kernel/core_uses_pid
最后生成的core dump文件名会加上进程ID.
2、另外可以通过修改kernel的参数，指定内核转储所生成的core文件的路径和文件名。
可以通过在/etc/sysctl.conf文件中，对sysctl变量kernel.core_pattern的设置。
#vim /etc/sysctl.conf 然后，在sysctl.conf文件中添加下面两句话：
kernel.core_pattern = /var/core/core_%e_%p
kernel.core_uses_pid = 0
保存后退出。
注：如果/proc/sys/kernel/core_uses_pid 这个文件的内容被配置成1，即使core_pattern中没有设置%p，最后生成的core dump文件名仍会加上进程ID。
这里%e, %p分别表示：
%c 转储文件的大小上限
%e 所dump的文件名
%g 所dump的进程的实际组ID
%h 主机名
%p 所dump的进程PID
%s 导致本次coredump的信号
%t 转储时刻(由1970年1月1日起计的秒数)
%u 所dump进程的实际用户ID
可以使用以下命令，使修改结果马上生效。
#sysctl –p /etc/sysctl.conf
请在/var目录下先建立core文件夹，然后执行a.out程序，就会在/var/core/下产生以指定格式命名的内核转储文件。查看转储文件的情况：
#ls /var/core
core_a.out_2456
更详细的内容或手动强制某个进程产生core dump的方法见链接：http://blog.csdn.net/wj_j2ee/article/details/7161586
帮助链接：http://www.cppblog.com/API/archive/2012/10/22/193644.html