内存MCE错误导致暴力扩充messages日志 以及chattr记录

    由于放假，好久没登过服务器，今天登上服务器查看日志意外发现：/var/log/messages文件竟然被撑到20多个G！！！赶紧查看是什么情况，首先，20多个G的文件根本无法查看，因此，我想到了split拆分文件，然后再细化查看，命令如下：

split -b 1024m messages mesg_tmp

其中，split命令-b选项可以识别的单位为m、k，即将messages文件切割成每块1024m大小的文件，mesg_tmp为前缀名，系统会默认在其后面加上aa、ab、ac.......，此外，split的-l选项可以指定行数进行切割，这样更方便在日志中进行查找。具体的可以  split --help

   打开文件之后，发现我之前的系统日志正常，只占了1500行左右，之后的20G基本都是以下消息：

Jan 31 04:53:10 !!liu!! kernel:
Jan 31 04:53:10 !!liu!! kernel: EDAC MC1: CE row 0, channel 0, label "CPU_SrcID#1_Channel#0_DIMM#0": 11 Unknown error(s): memory read on FATAL area OVERFLOW: cpu=8 Err=0001:0091 (ch=1), addr = 0x47b8c0740 => socket=1, Channel=0(mask=1), rank=0
Jan 31 04:53:10 !!liu!! kernel: sbridge: HANDLING MCE MEMORY ERROR
Jan 31 04:53:10 !!liu!! kernel: CPU 8: Machine Check Exception: 0 Bank 5: cc00034000010091
Jan 31 04:53:10 !!liu!! kernel: TSC 0 ADDR 28750fcc0 MISC 425e3e86 PROCESSOR 0:206d7 TIME 1454187190 SOCKET 1 APIC 20

   上网百度了一下，发现很多这种问题，基本都是说服务器由于内存问题而崩溃，大概是内存硬件故障，可以更好主板内存条或者cpu，等等， 还有说是MCE检测错误，建议我们安装Mcelog检测模块，以下是对MCE的官方说明：

What are Machine Check Exceptions (or MCE)?

A machine check exception is an error dedected by your system's processor. There are 2 major types of MCE errors, a notice or warning error, and a fatal execption. The warning will be logged by a "Machine Check Event logged" notice in your system logs, and can be later viewed via some Linux utilities. A fatal MCE will cause the machine to stop responding and the details of the MCE will be printed out to the system's console.

What causes MCE errors?

There most common reason for MCE events to occur are:

1.Memory errors or Error Correction Code (ECC) problems

2.Inadequate cooling / processor over-heating

3.System bus errors

4.Cache errors in the processor or hardware

由此可以推断确实应该是硬件方面的问题。 不过，很多人对此现象的最终解决办法是忽略该信息，-_-! 好吧。

既然忽略该信息，那我们就保留我们之前的1500行日志记录，删除其余的吧，结果又遇到了问题：

echo "" > /var/log/messages

提示messages文件无法被修改，不允许的操作。后来想可能是rsyslogd的服务一直在运行，daemon导致其无法修改？然后我：

lsof messages

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 7403 root 4w REG 8,6 1299113404 2686 messages

kill -9 7403
cat /dev/null > messages

仍然提示不允许的操作，什么鬼。。。。(lsof以后详细看)

再次百度，了解到这个messages文件可能被chattr保护了，我们lsattr一下，果然结果为-----a------，即设定了append属性，设定该参数后，只能向文件添加数据，而不能删除，多用于服务器日志文件安全。这个还真是看过，但是忘了。

结论：当我们以后发现用root都不能修改的文件时，大部分原因可能是该文件被chattr锁定了，通过chattr命令修改属性可以提高系统的安全性，但它不适合所有目录，例如，它不能保护/, /dev,  /tmp , /var目录，lsattr显示chattr设置的文件属性。

附一下chattr的参数说明： （来自：http://www.ha97.com/5172.html）

+ ：在原有参数设定基础上，追加参数。
- ：在原有参数设定基础上，移除参数。
= ：更新为指定参数设定。
A：文件或目录的 atime (access time)不可被修改(modified), 可以有效预防例如手提电脑磁盘I/O错误的发生。
S：硬盘I/O同步选项，功能类似sync。
a：即append，设定该参数后，只能向文件中添加数据，而不能删除，多用于服务器日志文件安全，只有root才能设定这个属性。
c：即compresse，设定文件是否经压缩后再存储。读取时需要经过自动解压操作。
d：即no dump，设定文件不能成为dump程序的备份目标。
i：设定文件不能被删除、改名、设定链接关系，同时不能写入或新增内容。i参数对于文件 系统的安全设置有很大帮助。
j：即journal，设定此参数使得当通过mount参数：data=ordered 或者 data=writeback 挂 载的文件系统，文件在写入时会先被记录(在journal中)。如果    filesystem被设定参数为 data=journal，则该参数自动失效。
s：保密性地删除文件或目录，即硬盘空间被全部收回。
u：与s相反，当设定为u时，数据内容其实还存在磁盘中，可以用于undeletion。
各参数选项中常用到的是a和i。a选项强制只可添加不可删除，多用于日志系统的安全设定。而i是更为严格的安全设定，只有superuser (root) 或具有CAP_LINUX_IMMUTABLE处理能力（标识）的进程能够施加该选项。