2020年4月10日17:04:14
从凌晨一点左右就开始收到不少最近新买的那台vps的警报信息，一直到早上八点多没间断过，想登陆vps上去看看，但ssh连接都很困难，好不容易登录上去了，输入个命令都不可能，一个字母等两分钟都没反应，只好在本地记事本上输入好然后粘贴上去，等两分钟出结果。
一看负载果然不低，1,5,15分钟都90+了，当时只想处理好问题，就没截图，后来截图的时候负载已经下去一些了：
还没开始处理就认为是web、php或者mysql把cpu耗光导致负载过高的，将php进程杀掉，负载没变化，mysql查询非常少，所以不是他们的问题，接着再将nginx杀掉，过两分钟即时负载果然立即下降到接近0了，果然是它的问题。
重新启动nginx，vps立即处于死机状态，无任何反应，控制台看了一下，cpu到200%了，负载飚升，难道是被人攻击了？
看了连接数，不多，网络占用带宽更是低得可怜，不像被攻击的样子。继而把nginx相关的日志都翻了个底掉，都没找什么异常。
折腾了两个小时了，感觉束手无策了…… 好无奈啊
想重启了事，说不定就能恢复，但骨子里极不情愿重启，还是想找到实质原因。
再看了一下top信息，us,sy,ni都很低，id为0，wa很高，很明显：都在等硬盘了……
想用 iostat -x 1 10 看看硬盘i/o情况，返回 -bash: iostat: command not found 没该命令，就yum install sysstat -y 进行安装，但是一直卡住好几分钟，我也没太在意，以为是负载太高，cpu硬盘都处理不过来，就继续等着，等了十几分钟还是这样没任何反应，等不了就手动kill了。
想看一下yum有没有被杀掉，突然发现：
ps aux|grep yum
root 4606 0.0 2.8 354648 28692 ? S 12:01 0:00 /usr/bin/python -tt /usr/sbin/yum-cron /etc/yum/yum-cron-hourly.conf
root 4607 0.0 0.0 113552 908 ? S 12:01 0:00 awk -v progname=/etc/cron.hourly/0yum-hourly.cron progname { ???? print progname ":\n" ???? progname=""; ??? } ??? { print; }
root 9885 0.0 2.8 352024 28860 ? S 13:01 0:00 /usr/bin/python -tt /usr/sbin/yum-cron /etc/yum/yum-cron-hourly.conf
root 9886 0.0 0.0 113552 956 ? S 13:01 0:00 awk -v progname=/etc/cron.hourly/0yum-hourly.cron progname { ???? print progname ":\n" ???? progname=""; ??? } ??? { print; }
root 14347 0.0 2.8 352024 28836 ? S 14:01 0:00 /usr/bin/python -tt /usr/sbin/yum-cron /etc/yum/yum-cron-hourly.conf
root 14348 0.0 0.0 113552 932 ? S 14:01 0:00 awk -v progname=/etc/cron.hourly/0yum-hourly.cron progname { ???? print progname ":\n" ???? progname=""; ??? } ??? { print; }
root 18575 0.0 2.8 352024 29032 ? S 15:01 0:00 /usr/bin/python -tt /usr/sbin/yum-cron /etc/yum/yum-cron-hourly.conf
root 18576 0.0 0.0 113552 968 ? S 15:01 0:00 awk -v progname=/etc/cron.hourly/0yum-hourly.cron progname { ???? print progname ":\n" ???? progname=""; ??? } ??? { print; }
root 22766 0.0 2.8 352024 28916 ? S 16:01 0:00 /usr/bin/python -tt /usr/sbin/yum-cron /etc/yum/yum-cron-hourly.conf
root 22767 0.0 0.0 113552 912 ? S 16:01 0:00 awk -v progname=/etc/cron.hourly/0yum-hourly.cron progname { ???? print progname ":\n" ???? progname=""; ??? } ??? { print; }
就觉得很不正常了，继而查了一下crond
ps aux|grep crond
root 20198 0.0 0.0 182380 944 ? S 07:37 0:00 /usr/sbin/crond -n
root 20202 0.0 0.0 182380 944 ? S 07:37 0:00 /usr/sbin/crond -n
root 20252 0.0 0.0 182380 944 ? S 07:43 0:00 /usr/sbin/crond -n
root 21525 0.0 0.0 182380 940 ? S Apr09 0:00 /usr/sbin/crond -n
root 22776 0.0 0.0 182380 944 ? S 08:19 0:00 /usr/sbin/crond -n
root 22808 0.0 0.0 182380 944 ? S 08:23 0:00 /usr/sbin/crond -n
root 22832 0.0 0.0 182380 944 ? S 08:25 0:00 /usr/sbin/crond -n
用systemctl stop crond停止服务，发现几十个crond进程还是在，直接手动强制kill -9 crond
又看了下/var/log/secure，很多错误信息：
Apr 10 09:07:19 server307 crond[24888]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24889]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24887]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24890]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24896]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24895]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24894]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24897]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:20 server307 crond[24893]: pam_systemd(crond:session): Failed to create session: Input/output error
Apr 10 09:07:33 server307 crond[24898]: pam_systemd(crond:session): Failed to create session: Connection timed out
Apr 10 09:08:36 server307 crond[24915]: pam_systemd(crond:session): Failed to create session: Connection reset by peer
Apr 10 09:08:36 server307 crond[24917]: pam_systemd(crond:session): Failed to create session: Connection reset by peer/var/log/messages里也有很多关于crond的信息。
把cron的文件夹都看了一下，看到关于yum的，直接删除了这两个文件
/etc/cron.hourly/0yum-hourly.cron
/etc/cron.daily/0yum-daily.cron
yum-cron是用来自动更新Linux系统的，我没这个需求，所以直接停止，删掉。
禁止yum-cron开机启动
systemctl disable yum-cron.service
停止yum-cron运行
systemctl stop yum-cron.service
查看yum-cron状态
systemctl status yum-cron.service
更加干净的当然是直接卸载
yum -y remove yum-cron
不知道什么原因导致yum坏掉了，一直处于执行中，也可能是每天，每小时都会启动新的yum-cron进程，不断的积累导致数量非常可观的进程，同时抢占/写入数据将自己搞坏了吧，导致恶性循环，最后导致狂读硬盘将I/O耗光……
将yum-cron和crond都杀掉后vps就恢复正常了，也折腾蛮久了
由于yum已经废，试着用了几个方法处理，均无效，rebuilddb也没用，又没更多时间去研究，所以就先不管它了，服务器能正常运行就行。
小回顾
如果当时选择重启vps肯定也能将问题搞定，快速而有效，因为重启后那么多的yum-cron和crond进程都不存在了，不过这只是暂时的，经过一段时间的积累这些进程又会死而复生，负载又继续飚升，问题又会重现。
还好我没放弃……