工作中有个脚本
定时登到服务器上去，df一下看看分区使用情况
如果有使用率超过80%的
就报警(email & sms)
最近发现有台机器报了
等上去看，处理了一下(直接rm文件)
过段时间又报
再上去看，用du来找哪个目录占的空间大的时候
发现被报的那个分区其实占用率并不高
但用df看还是超警戒线(80%)
我知道肯定是
有进程没有释放某些已经被删除了的文件
这种事情以前也碰到过
一般重起机器肯定会把这些进程占用的空间释放掉
但一定要重起机器才能解决问题吗
当然不是
只要停掉那些打开了已经被删除文件的进程就行了
于是
lsof | grep deleted
果然一下子就找到了
然后kill之
再df看
就正常了
教训：
不要随便删除正在被打开的文件。
作为系统管理员
tail这个命令应该是很熟悉的
经常会用到用”-f”的参数来监控log文件（看着log一屏屏的翻，比较有成就感：）
好像在实时log分析的程序里
大家的思路大多也是用tail -f某个log文件
然后再用管道传给程序处理
但这样有一个问题
就是当系统logrotate这个log文件的时候
系统会重建这个log文件
在这个时候
如果监控这个log文件用的是命令”tail -f“的话
就会接不到任何新的内容
一般的做法是在这个log文件logrotate之前把监控的脚本程序(包含tail -f)都kill掉
在logrotate之后呢
再重新起起来
但是这里也许有一种更好的解决方法：用参数”-F”代替”-f”
“-F“相当于”–retry -f”
用这个参数，就算原来的log文件被重建
tail还能重新打开新的log文件，继续接收log内容
我做过简单的测试
在一个shell里用一个脚本不停地往一个log文件里写东西
在另外一个shell里用tail -f来读
当第一个shell里停掉程序，删掉log文件，再重启程序(同时重建了log文件)的时候
另外那个shell里读这个log文件的tail再没有任何新的显示
但如果我们用tail -F来读
同样在头一个shell里那样处理后
这边出一个“
tail: ‘xxxxxx’ has been replaced; following end of new file
”
的提示后又接着显示log文件里的内容了
这个直接导致了我在apache里设置的对xml文件的压缩(deflate)未能成功
因为我的配置文件里是这么写的：
AddOutputFilterByType DEFLATE text/html text/plain text/xml
而且这种配置在系统自带的apache里是没有问题的
后来仔细查了查
发现系统自带的apache
用的是/etc/mime.types文件
而源代码编译的
用的则是conf/mime.types文件
这两个文件对xml文件的internet media type解释就是不一样：
一个认为是text/xml
另外一个则认为是application/xml
知道原因了
解决问题起来就顺利多了
把配置文件里AddOutputFilterByType那句后面加上application/xml
再重启就ok了
