移动sftp.log文件导致监控不可用sftp.log无新日志的写入--切日志引发的血案

这周三突然发现一个部署了很久的监控脚本失效报警了，这个脚本内容其实很简单就是抓一下sftp.log里边的某个用户下载文件的记录，如果上次来下载文件的日期超过两天就报警。
结果周三早上发现从上周一开始之后sftp.log就一条都没有往里写过。这情况确实是有点诡异。开始以为是对方没有来下载就给对方发了个信问问情况，但是对方说下载成功没啥问题。这就轮到我们懵逼了，看看message和secure都能往里写其他的日志也都挺正常的，就只还有sftp.log停留在了3月19日。网上查了半天也没见有人遇到过类似的情况。。。抓狂。开始逐个文件排查，先看/etc/ssh/sshd_config正常，没问题，在看/etc/syslog.conf也是正常没啥问题。又看crontab也没有新加奇怪的计划任务。查了一天没结果就想着试试重启一下syslog服务看看情况会不会好点。重启完本地用xsell的sftp试了试结果能访问但就是不记日志。
周四查了一天没有结果，晚上睡觉的时候突然做梦想起来我周一切过一次日志，动手操作的时候为了方便先对sftp.log有个mv操作。然后又MV回来的会不会是mv的过程中造成sftp服务不认这个文件了。第二天上班来了赶紧试试，重启了一下sshd然后在用xshell试了一下，成了。确实是mv sftp.log导致的。观察到早上九点半没问题，一切正常，监控脚本也恢复了。
记录一下这个事情，下次再要切日志的时候不要偷懒直接mv还是老老实实的用sed切。或者mv之后千万要记得重启一下sshd服务。
写在最后的话：没有什么事情是一次重启服务不能解决的，如果有那就reboot服务器试试