原来都是crontab惹的祸(inode 100%处理解决)，服务器系统差点重置了/呜呜呜

当服务器一连串出现这些Authentication token manipulation error或passwd: gkr-pam: couldn’t update the login keyring password:或E303: Unable to open swap file for “[No Name]“, recovery impossible以及出现No space left on device的问题的解决方法

大家可不要小瞧linux磁盘根目录爆满哈，今天要交流的就是磁盘100%之后发现的后遗症，并成功解决。

背景

发现问题一

Authentication token manipulation error  (给用户更改密码的时候报错)

第二天又接到机房的电话，还是上次的那个磁盘100%的服务器，现在无法给账户更改密码，报错Authentication token manipulation error给账户更改密码，怀疑服务器还存在问题。如果还不清楚什么情况，还请看下我上一篇博客

接上一个博客：cpu负载4800，根目录磁盘100%，问题排查和解决

因为当时在开周例会，也没及时的响应这个问题，毕竟机房的大佬才是专业的，哈哈哈，好吧，真正原因是因为开会实在太忙，没来的及安排

发现问题二

passwd: gkr-pam: couldn’t update the login keyring password  (查看系统日志发现)

机房接着发聩说查看系统日志发现了passwd: gkr-pam: couldn’t update the login keyring password这个问题，当时自己的第一发应就是sudo提权是不是出现了问题呢，因为之前遇见过类似的问题（印象中），但是机房反馈说可以正常的sudo到超级管理员用户，因为当时在开会，也没到服务器上面验证，安排人员和机房进行对接问题，没想到爆出了更多的问题。

发现问题三

E303: Unable to open swap file for “[No Name]“, recovery impossible  （vim编辑/etc/passwd文件的报错）

不一会接到电话说，本来想对一下passwd和shadow文件的一致性的，但是vim /etc/passwd的时候报错无法open swap。
有点意思了哈，这台服务器也很久了，接连出现了这几个奇怪现象，安排继续排查问题，排查磁盘空间也是充足的，就是不知道问题出现在了哪里，当时已经商量着走变更方案重置linux系统了。

发现问题四

No space left on device   (创建文件的时候发现)

检查磁盘空间发现磁盘空间充足

好吧，是时候揪出真凶了

发现真凶

如果大家看了我上一个博客的时候就会发现一个问题，磁盘曾经达到过100%，这里大家就得注意下了，还有一个cpu4800+,也就是说磁盘满了，但是cpu还是在干活的，在加上和定时任务有关，磁盘明明很充足，但是还是报磁盘空间不足，那就只有一个情况了，那就是系统文件的indoe号已经满了

简单的介绍下inode号的作用

理解inode号只需要简单知道3点
第一、linux中每个文件都必须有一个inode，无论文件的大小。
第二、每个inode都有一个号码，操作系统用inode号码来识别不同的文件。
第三、inode号是有上限的，达到上限就没有indoe号分配就无法创建文件。

解决问题

检查inode号使用情况

命令:df -hi    h:人性化显示也就是加上单位方便观看，i：代表的就是展示inode号信息

查找原因

出现Indeo号用完磁盘没有用完，当前本人就知道一种情况了，那就是小文件太多，占用了大量的Indoe的号，事实呢也就这种情况
还有就是出现这种情况，小编遇见做多的也就是邮件服务里面，尤其是crontab定时任务，为什么这样说呢，看看下面小编的解释

原因分析

• 想知道原因的话，那就的先来弄清楚定时任务的原理
• crontable创建定时任务，
• 如果定时任务脚本书写不规范，有回显也就是说定时任务执行完后会有结果输出，
• 如果设定定时任务的用户当前在线，那么这些结果就会在屏幕上显示了出来给用户，
• 但是如果配置定时任务的用户不在线，那crontab就会默认发邮件来通知当前用户。

那么问题来了
如果一个定时任务1分钟执行一次，那也就是说他会一分钟生成一个邮件文件(用户不在线的情况下)，时间长了，那邮件文件的数量可想而知了,这也就是这个问题的原因了。

查看小文件

因为小编之前处理这个事情较多了，别问小编是通过什么命令，什么方法来查找小文件在哪里的，小编只能告诉大家，凭经验，速度是最快的，所以说咱们不怕问题，最可怕的就是发生问题后不及时整理。

小文件(crontab的邮箱文件路劲):/var/spool/postfix/maildrop				不建议大家直接ls查看，因为会把终端卡死掉的哈，除非有时间慢慢等他显示出来

检查小文件数量

清理小文件

小编是老手哈，清理前第一时间想到的是备份，但是吧，小编条件不允许，如果大家条件允许的话，还是要备份的，虽然知道这些文件没有什么用，但是还是要养成一个良好的随手习惯

这里还有一点需要大家注意的哈，就是不能直接cd到路径下面使用rm -rf *命令来进行删除

• 为什么不能使用rm -rf *
• 身为运维人员第一要考虑的是数据的安全可靠，如果你执行错目录了呢，那岂不是得不偿失
• 会报错，小编也忘了报什么错，好像是名称太长之类的
• 好吧，小编承认，这样太残暴，不敢执行

执行命令

在/var/spool/postfix/maildrop目录下，一定要检查好目录

# ls | rm -f    #因为文件太多会执行很慢#这里需要注意的是我没有使用-r参数，为什么呢，因为-r参数会对当下的目录执行清理操作的，咱们要清理的是文件，减小不必要的风险然后重新打开一个终端，不停的检查df -hi 来检查inode号是不是慢慢的空闲了出来

检查结果

当然看当前需要，小编这个是将inode号空闲出来了53%,就直接ctrl + c终止执行了，需要Inode的空闲多少还是看自己需求了

最后机房验证所有的功能都已经恢复正常，业务也验证了对业务没有影响，这里小编还是要提示一下，别看小编这样连续的操作，当然也是走了变更流程的哈。

结束语

工作就是积累这些一点一滴，努力加奋斗成就辉煌