记一次服务器内存报警的解决

事件背景

周六的早晨收到服务器内存告警邮件，吓一大跳，赶紧爬起来，不然很严重的好吗

---

查找报警内存

1、 查出报警的内存目录
命令：df -h
查询结果： /app 目录 use 是 98%,都187G了，总分配大小才197G，快要爆了好不好 ，极度危险！

2、继续深入查询
进入/app目录，查看各文件或文件夹大小：ls -lh
发现是/app/logs_back 目录文件非常大，而且还在飞速增长！

---

分析报警原因

此文件夹/app/logs_back 是服务器对系统应用的日志文件做备份的。
进一步查看该文件夹发现，里边的备份文件每分钟都会生成新的。点开每个备份的文件夹发现都是一样的日志，都是近一个礼拜的日志文件。

这样原因就很清晰了，是服务器的备份策略出现了问题。本应每隔七天备份这七天的日志，现在是每分钟都在备份这七天的日志。很明显是备份的定时任务cron语法使用错误。

查看服务器备份定时脚本： crontab -e 

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
* * */6 * * /bin/sh  /app/logs_back.sh

问题很明显了，定时语法有误，前面两位是 * ， 意味着每隔6天后的每时每分都会执行，严重的语法错误，不知道是哪位小哥。问了下项目组是一位年长的小哥搞错了。

---

问题解决

1 赶快删除这个文件夹 /app/logs_back,不让文件继续暴涨
2 修改定时语法，重新执行定时任务

0 0 * * 6 /bin/sh  /app/logs_back.sh

每礼拜六的00:00执行。

---

补充：

1. Linux定时任务相关指令

• crontab -l 查看定时程序脚本执行列表
• crontab -e 编辑定时程序脚本执行列表 进入VI编辑模式
• crontab -u 设定某个用户的cron服务，一般root用户在执行这个命令的时候需要此参数
• crontab -r 删除某个用户的cron服务

2. 服务器定时语法

它和我们在spring使用的cron语法是一样的，spring比这个还更好一点：多了个秒。

其实在定时的文件也有语法介绍【有的系统可能没有，比如我的阿里云】，这里搬来大家共勉：

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

另:

• “*” ：代表取值范围内的数字,
• “/” ：代表”每”,
• “-” ：代表从某个数字到某个数字,
• “,” ：分开几个离散的数字