事情经由
昨天早上，打开电脑创造自己的博客网站打开不了，准备远程登录做事器查看问题，创造做事器远程不上。没办法，登录阿里云后台，重启做事器。重启完成后，网站能正常打开，以是当时就不以为然，以为阿里云那边是不是出了什么毛病。
到了下午的时候，创造网站又打不开了，而且又远程连接不了做事器。进入阿里云掌握台，查看监控创造cpu跑满了。只能再重启做事器，等重启完成后再远程连接上去，这次须要好好排查问题。
办理问题
当时首先想到的是中病毒了，先不管那么多，第一步是找到那些耗cpu的进程杀去世。利用top命令，查看耗cpu的进程有哪些。一看就明白了，都是bzip2搞得鬼。
杀进程的过程创造一个问题，便是这些进程杀去世了，过一会又涌现了。这种征象，我知道肯定要找到他们的父进程，擒贼先擒王。
# ps -lA | grep bzip2
0 R 0 1965 1964 44 80 0 - 3435 - ? 00:01:43 bzip2
0 S 0 1981 1980 33 80 0 - 3435 pipe_w ? 00:00:56 bzip2
0 R 0 1997 1996 30 80 0 - 3435 - ? 00:00:31 bzip2
0 R 0 2013 2012 27 80 0 - 3435 - ? 00:00:07 bzip2
0 R 0 2024 2023 15 80 0 - 3435 - ? 00:00:00 bzip2
但是创造他们的ppid不是同一个，这就让我很迷惑了。我打算用进程树看看
pstree -up
这时候，我就知道了，原来是自己的定时脚本有问题。那么我须要做以下几件事：
关闭crond做事crontab -e 将weekly.sh去掉杀掉那些耗cpu的进程# 关闭
[root@iz8vb626ci0aehwsivxaydz ~]# kill 1622
[root@iz8vb626ci0aehwsivxaydz ~]# systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Tue 2019-11-12 10:44:32 CST; 10s ago
Main PID: 1622 (code=exited, status=0/SUCCESS)
# 修正crontab -e
# 杀掉耗cpu进程，下面的命令实行了好几遍，才将所有耗cpu进程全部杀掉了
ps -lA | grep bzip2 | awk '{print $4}' | xargs -n 10 kill -9
问题缘故原由与思考
刚开始，我以为是自己的shell脚本有问题，涌现去世循环导致问题涌现。但是查看脚本，创造没有问题，没有去世循环的情形涌现。一韶光，百思不得姐。
#!/bin/bash
# 每周备份脚本
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
export
backdir=/backup/weekly # 备份目录
[ -z "$backdir" ] || mkdir -p $backdir
dirs=(/etc /home /root /usr /var/spool/cron /var/spool/at) # 须要备份的目录
for dir in ${dirs[@]}
do
if [ ! -d $dir ];then
continue
fi
cd $backdir
tar -jcpf $(basename $dir)_$(date +%Y%m%d).tar.bz2 $dir
done
# 删除mtime大于30天的文件
find $backdir -mtime +30 -name .tar.bz2 -exec rm -f {} \;
过了很永劫光，终于找到了缘故原由所在，原来是自己的定时任务写法有问题
3 1 /root/bin/weekly.sh 1>/dev/null 2>&1
我原来的想法是每周1凌晨3点实行一次备份脚本，但是这样写的结果是每周一凌晨3点的每分钟都会实行该脚本一次。精确的写法该当如下：
# 每周一凌晨三点零一分实行该脚本
1 3 1 /root/bin/weekly.sh 1>/dev/null 2>&1
问题办理了，缘故原由也找到了。自己该写一个做事器资源监控脚本了。
