yum把自己搞死了 然后又把服务器弄死了(yum命令卡死的解决办法)

支付宝内搜索 9155838 即可领现金红包 每天都能领哦

2020年4月10日17:04:14
从凌晨一点左右就开始收到不少最近新买的那台vps的警报信息,一直到早上八点多没间断过,想登陆vps上去看看,但ssh连接都很困难,好不容易登录上去了,输入个命令都不可能,一个字母等两分钟都没反应,只好在本地记事本上输入好然后粘贴上去,等两分钟出结果。

一看负载果然不低,1,5,15分钟都90+了,当时只想处理好问题,就没截图,后来截图的时候负载已经下去一些了:
vps负载很高

还没开始处理就认为是web、php或者mysql把cpu耗光导致负载过高的,将php进程杀掉,负载没变化,mysql查询非常少,所以不是他们的问题,接着再将nginx杀掉,过两分钟即时负载果然立即下降到接近0了,果然是它的问题。

重新启动nginx,vps立即处于死机状态,无任何反应,控制台看了一下,cpu到200%了,负载飚升,难道是被人攻击了?

看了连接数,不多,网络占用带宽更是低得可怜,不像被攻击的样子。继而把nginx相关的日志都翻了个底掉,都没找什么异常。

折腾了两个小时了,感觉束手无策了…… 好无奈啊 心灵博客 http://blog.dngz.net/

想重启了事,说不定就能恢复,但骨子里极不情愿重启,还是想找到实质原因。

再看了一下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; }

很多yum-cron很多进程

就觉得很不正常了,继而查了一下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

很多crond进程
用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进程都不存在了,不过这只是暂时的,经过一段时间的积累这些进程又会死而复生,负载又继续飚升,问题又会重现。
还好我没放弃……

-----------2020年4月25日12:09:20 更新-------------

搞定yum命令无反应的办法

今天vps上遇到一点问题,一个命令执行报错,可能缺少dbi组件,由于知道yum不能用,所以用rpm -qa |grep perl-DBD | grep MySQL 查询是否存在这个包,结果也是和yum一样,卡住不动,觉得和yum很大的关系了。

如果不存在这个dbi包编译的话一堆依赖会非常麻烦,为省事就必须要用到yum了。

为了搞定rpm命令执行无反应/卡死的问题,先把rpm的数据库清理并重建一下:

rm -f /var/lib/rpm/__db.*
rpm -vv -rebuilddb

同时也看看/etc/cron.daily/里面有没有rpm相关的东西,如有就删掉。

然后rpm命令执行卡死的问题解决了,rpm命令执行正常了。

然后,然后 重头戏来看了!

yum命令执行卡住的问题也自动解决了!!

真是开心,哈哈哈。

坑:上次执行的是yum -vv --rebuilddb,醉了

推荐文章

已有 31 条评论
  1. ZAPRO

    大佬就是大佬,死磕到底!

    ZAPRO 回复
    1. xylx

      @ZAPRO

      猫叔别换头像别换名字,别人都会不认识你了

      xylx 回复
  2. 张波博客

    我以为重启可以解决问题呢,呵

    张波博客 回复
    1. xylx

      @张波博客

      重启大法也能暂时解决一下,过几天出问题再重启了事。又或者设置每天凌晨自动重启(有些人有这个的爱好)。

      xylx 回复
    2. 萧瑟

      @张波博客

      有些故障不一定重启就能解决的

      萧瑟 回复
  3. Mr.Chou

    换做是我重启还是这样可能会奔溃,还是虚拟机省心..不行就找管理。

    Mr.Chou 回复
  4. 叶先生博客

    折腾的越多,懂得的也就越多

    叶先生博客 回复
  5. 石樱灯笼

    yum的健壮性很强的,一般不会坏(除非你用的Centos5.5之前的版本)。
    我觉得你还是研究下是什么把yum搞坏了吧。

    石樱灯笼 回复
    1. xylx

      @石樱灯笼

      centos7,暂时不知道什么原因弄坏的yum,它自己作死😂

      xylx 回复
      1. 石樱灯笼

        @xylx

        你这和重启解决问题没什么太大区别

        石樱灯笼 回复
        1. xylx

          @石樱灯笼

          至少不会再次出现这个问题了,有空再折腾

          xylx 回复
  6. Sam.Z

    能找到问题点就很开心,这就是折腾的意义,😀

    Sam.Z 回复
    1. xylx

      @Sam.Z

      是的,折腾就这么点收获了

      xylx 回复
  7. 静水流深

    大佬大佬

    静水流深 回复
  8. 响石潭

    密密麻麻的数据,看着眼花缭乱,越折腾越带劲

    响石潭 回复
    1. xylx

      @响石潭

      折腾这个一点都不带劲o(╥﹏╥)o

      xylx 回复
  9. 小陆花

    说实话,我看不懂~我博客安装都是在网上找的教程。而且bt面板还是以前的低版本,奈何当时白嫖阿里云选了个低系统,现在也不能升级~

    小陆花 回复
    1. xylx

      @小陆花

      够用就行了,升级可能会出一堆问题,实在想弄还不如重装高版本。

      xylx 回复
  10. wys

    楼上说的好:大佬就是大佬,死磕到底!

    wys 回复
  11. 小姚工作室

    是个高手

    小姚工作室 回复
  12. linlinxing

    恩啊。大佬就是大老。
    我以为在炒股。🤦‍♂️

    linlinxing 回复
  13. 梦之源泉

    牛X啊。我看的都晕了。如果是我就是重启大法好。

    梦之源泉 回复
  14. ZAERA

    不想折腾的人,第一件事就是重启,毕竟重启能解决90%的问题

    ZAERA 回复
  15. Escher

    360的亲戚吧。。。。。我杀我自己yum版本!!!

    Escher 回复
  16. 趣知识

    看上去真复杂

    趣知识 回复
  17. 林三

    我觉得主机能玩到vps的都是比我厉害,所以允许我先致敬,哈哈!

    林三 回复
  18. 留芳网

    我也遇到BUG了,现在还没解决,都快一个月了,后台进不去,无限重复到登录页面。

    留芳网 回复
    1. xylx

      @留芳网

      你所说的后台是什么?

      xylx 回复
      1. 留芳网

        @xylx

        就是wordpress的后台啊。

        留芳网 回复
        1. xylx

          @留芳网

          这里讨论的是linux...

          xylx 回复
  19. MindYoga

    有意思!

    MindYoga 回复
发表新评论