最近发现ftp下无法上传文件，仔细一看原来是在根目录下生成了不少的core文件，每个都在30M左右，导致磁盘空间满了，所以无法继续上传文件。
删除了没多长时间，同样的问题再次出现，google以后发现core文件是一种临时调试而生成的文件，可能是某个应用程序出错而生成的，这些垃圾文件一般没有太大的害处，随时都可以删除。
一直苦苦搜索也没有找出能有效阻止core文件生成的方法，目前只能采取最笨的方法，只要发现生成了就直接删除，不过这样子真的很麻烦，大家有没有什么好的方法可以给俺分享下。
所以用F2blog的朋友，磁盘不够用的时候记得检查一下你的blog目录下是不是有core这样的文件，删除掉以后就给你腾出空间来了：）
关于core文件的相关知识可以从下面的介绍中了解一下：
//—————————————————————
1. core文件的简单介绍
//—————————————————————在一个程序崩溃时，它一般会在指定目录下生成一个core文件。core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。
//—————————————————————
2. 开启或关闭core文件的生成
//—————————————————————用以下命令来阻止系统生成core文件:
ulimit -c 0
下面的命令可以检查生成core文件的选项是否打开:
ulimit -a
该命令将显示所有的用户定制，其中选项-a代表“all”。也可以修改系统文件来调整core选项
在/etc/profile通常会有这样一句话来禁止产生core文件，通常这种设置是合理的:
# No core files by default
ulimit -S -c 0 > /dev/null 2>&1
但是在开发过程中有时为了调试问题，还是需要在特定的用户环境下打开core文件产生的设置
在用户的~/.bash_profile里加上ulimit -c unlimited来让特定的用户可以产生core文件
如果ulimit -c 0 则也是禁止产生core文件，而ulimit -c 1024则限制产生的core文件的大小不能超过1024kb//—————————————————————
3. 设置Core Dump的核心转储文件目录和命名规则
//—————————————————————/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0
proc/sys/kernel/core_pattern可以设置格式化的core文件保存位置或文件名，比如原来文件内容是core-%e
可以这样修改:
echo "/corefile/core-%e-%p-%t" > core_pattern
将会控制所产生的core文件会存放到/corefile目录下，产生的文件名为core-命令名-pid-时间戳
以下是参数列表:
%p – insert pid into filename 添加pid
%u – insert current uid into filename 添加当前uid
%g – insert current gid into filename 添加当前gid
%s – insert signal that caused the coredump into the filename 添加导致产生core的信号
%t – insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h – insert hostname where the coredump happened into filename 添加主机名
%e – insert coredumping executable name into filename 添加命令名//—————————————————————
4. 使用core文件
//—————————————————————在core文件所在目录下键入:
gdb -c core
它会启动GNU的调试器，来调试core文件，并且会显示生成此core文件的程序名，中止此程序的信号等等
如果你已经知道是由什么程序生成此core文件的，比如MyServer崩溃了生成core.12345，那么用此指令调试:
gdb -c core MyServer
以下怎么办就该去学习gdb的使用了//—————————————————————
5. 一个小方法来测试产生core文件
//—————————————————————直接输入指令:
kill -s SIGSEGV $$
谢谢