centos7根目录老是生成core. 把磁盘占满？

查看core file size： ulimit -c

core file size：

unlimited：core文件的大小不受限制

0：程序出错时不会产生core文件

1024：代表1024k，core文件超出该大小就不能生成了

设置core文件大小： ulimit -c fileSize

注意：

尽量将这个文件大小设置得大一些，程序崩溃时生成Core文件大小即为程序运行时占用的内存大小。可能发生堆栈溢出的时候，占用更大的内存 Linux就该这么学

设置core文件的名称和文件路径

默认生成路径：输入可执行文件运行命令的同一路径下

默认生成名字：默认命名为core。新的core文件会覆盖旧的core文件

a.设置pid作为文件扩展名

1：添加pid作为扩展名，生成的core文件名称为core.pid

0：不添加pid作为扩展名，生成的core文件名称为core

修改 /proc/sys/kernel/core_uses_pid 文件内容为: 1

修改文件命令： echo "1" >/proc/sys/kernel/core_uses_pid

或者 sysctl -w kernel.core_uses_pid=1 kernel.core_uses_pid = 1

用以下命令来阻止系统生成core文件:

ulimit -c 0

在/etc/profile通常会有这样一句话来禁止产生core文件，通常这种设置是合理的:

# No core files by default

ulimit -S -c 0 >/dev/null 2>&1

从接触unix开始就一直听到和遇到core dump，特别是刚学着使用C语言在AIX下编写程序的时候，core dump更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core dump，对于银行核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core dump，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core dump的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。

虽然常常遇到core dump，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书......少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈

core dump，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等， *** 作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core dump就是其中的一种。如果进程core dump，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core dump。平常大家说某某进程core dump了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。

AIX上提供了dbx工具可以对core dump进行调试，协助定位引起core dump的代码。最普通的语法是：

dbx 应用名 core文件， 然后使用where命令来显示调试信息

一般来讲，根据工作中遇到的情况，dbx还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时，dbx显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core dump时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。

---