本文共 5758 字,大约阅读时间需要 19 分钟。
# ps -ef|grep sendmail |wc -l
461# ps -ef|grep postdrop |wc -l
460# ps -ef|grep CROND|wc -l
460 等过了会,没有做任何操作,屏幕里就开始输出资源紧张了,看来问题还是有些严重了。 bash: fork: retry: Resource temporarily unavailable bash: fork: retry: Resource temporarily unavailable bash: fork: retry: Resource temporarily unavailable 简单明确了问题,发现是这三个进程占用了大量的进程资源,为了先修复问题,实用下面的脚本kill掉sendmail的进程。 # ps -ef|grep sendmail| awk '{print "kill -9 "$2}' 清理之后马上就恢复了正常。 $ ps -ef|wc -l 1173 这个时候开始逐步分析排查,查看了crontab里面也没有发现频繁的crontab任务。 查看系统日志发现了这么一段内容 /var/log/maillog Sep 30 09:28:51 xxxx postfix/postdrop[42358]: warning: mail_queue_enter: create file maildrop/236034.42358: No space left on device Sep 30 09:28:51 xxxx postfix/postdrop[39782]: warning: mail_queue_enter: create file maildrop/236872.39782: No space left on device Sep 30 09:28:51 xxxx postfix/postdrop[40086]: warning: mail_queue_enter: create file maildrop/237156.40086: No space left on device 但是查看文件系统情况没有问题,空间还是很充足的。 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda7 6.0G 949M 4.7G 17% / tmpfs 16G 0 16G 0% /dev/shm /dev/sda1 124M 53M 65M 45% /boot /dev/sda2 6.0G 1.6G 4.1G 29% /usr /dev/sda3 4.0G 1.5G 2.3G 40% /var 那么空间充足,为什么还有问题,其实使用df -i 就能看出端倪。 # df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda7 393216 17569 375647 5% / tmpfs 4103447 1 4103446 1% /dev/shm /dev/sda1 32768 45 32723 1% /boot /dev/sda2 393216 77762 315454 20% /usr /dev/sda3 262144 262144 0 100% /var /dev/sda8 71000064 299827 70700237 1% /U01 df 查看的i选项就是inode的信息,这个命令选项的含义如下: -i, --inodes List inode usage information instead of block usage. An inode (short for index node) contains information about a file such as its owner, permissions, timestamps, and location on the disk. 其实文件本身不大,但是数量巨大,就会有这种问题。可以看到这个目录下有25万个这样的细小文件。 maildrop]# du -sh . 1023M . maildrop]# ll |wc -l 259903 因为这个进程下的文件都是比较早的,所以可以先删除一部分旧文件。 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 4B2722D -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 5C1A038 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 6EE0539 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 81A5169 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 9203979 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 A5D4393 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 B7B90A0 -rwxr--r-- 1 oracle postdrop 471 Mar 20 2015 CA347A4 当前用户的资源情况如下: $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 256313 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 2047 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 所以最后使用下面的脚本开始清理这些碎片文件,先腾出来一部分空间来。 find . -mtime +60|xargs ls -lrt|head -100|awk '{print "rm -f " $9}' > ~/clean.sh 清理了部分文件之后,警告信息变成了下面这种。 Sep 30 10:42:01 xxxx postfix/sendmail[15445]: warning: the Postfix sendmail command has set-uid root file permissions Sep 30 10:42:01 xxxx postfix/sendmail[15445]: warning: or the command is run from a set-uid root process Sep 30 10:42:01 xxxx postfix/sendmail[15445]: warning: the Postfix sendmail command must be installed without set-uid root file permissions Sep 30 10:42:16 xxxx postfix/postdrop[15451]: warning: unable to look up public/pickup: No such file or directory 这个部分对自己来说就是新手了,也不敢妄自乱试验,咨询了下linux高手,他们发现sendmail有问题,不知道是最开始初始化的时候没有装好还是其它原因,建议还是重新安装。 然后又开始着实配置各种yum环境,费了一番功夫。 # yum reinstall sendmail 当然安装的时候需要有系统用户smmsp和用户组smmsp,最后重新安装后日志里面就恢复了正常, 这个问题的原因我觉得是一个遗留问题,安装阶段就有点小问题,但是没有引起重视,结果随着时间的推移,慢慢积累成了大问题。 所以通过这个例子可以看到对于inode的监控也是需要的,同时监控异常的进程情况也会提前发现不少问题。来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-1812698/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-1812698/