记录一次Linux机器清理空间的过程

项目中要改一下Nginx的配置，于是通过跳板机登录了Nginx机器。结果看到这个景象：

刺激，服务器空间没了，先解决一下这个问题吧，不然也没法写入，而且服务器也没法正常运行了。

分析：
这台机器只负责运行Nginx，空间占满很大程度上是因为日志生成太多。

根据分析思路，我先去看一下磁盘空间的使用状况：

命令：df -h

确实有个使用率已经高达百分百的块，但是我对这一块不了解，不知道到底是哪一块这么满，于是到根目录下看一下到底是哪个目录这么大：

命令：du -sh /*

发现了，原来是home，通过按照大小查看当前目录下所有文件进去，最后定位到Nginx目录：

指令：du -s * | sort -nr

确认error.log可以删除之后，删除文件：

指令： rm error.log (不要随便用rm -rf)

结果发现，清理之后系统仍然提示空间不足，明明文件已经清楚，到底咋回事呢？我又看了一下，确认是否删除了正确的文件：

指令：du -sh * | sort -nr

可以看出，刚才占空间59G的error日志已经删除，但是还是空间不足。这时我想到，是不是因为nginx正在运行，这个error.log文件正在被占用，进行删除操作被存起来了，等待nginx进程结束之后才能删除。于是查看删除队列中的信息：

指令：lsof | grep deleted

果然不出所料，这些文件实际上还存在，所以接下来要暂时关闭一下nginx释放进程，好让系统执行这些删除任务，但是考虑到可能有人正在使用nginx，为了影响最小化，于是使用响应速度更加快的reopen操作，重启nginx（重启指令只有一条，等于stop+start，执行起来肯定比手动输入stop然后再start要快，影响更小）：

指令： nginx -s reopen

重启的时候，明显感到卡顿了一下，看来是已经执行了删除任务，清理掉了59G的文件，检查一下：

指令：还是 lsof | grep deleted

可以看出，文件已经被清理掉了。
用du指令检查一下，可以看出home目录已经成功瘦身59G，而且系统已经不提示空间已满了~：

总结：
清理文件要注意，小心使用rm -rf。
清理之后仍没空，查看是否被占用。