00:00:00 /usr/sbin/postdrop -r # ps -ef|grep sendmail |wc -l 461 # ps -ef|grep postdrop |wc -l 460 #...-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
$ ps -ef|grep sendmail |wc -l 1317 $ ps -ef|grep postdrop|wc -l 1317...-rwxr--r-- 1 root postdrop 641 Aug 27 23:10 CEADC52C -rwxr--r-- 1 root postdrop 497 Aug 27 23:10 CEB7352D...-rwxr--r-- 1 root postdrop 516 Aug 27 23:10 E62A552E -rwxr--r-- 1 root postdrop 632 Aug 27 23:20 CCF8F530...-rwxr--r-- 1 root postdrop 506 Aug 27 23:20 CCDD852F -rwxr--r-- 1 root postdrop 516 Aug 27 23:20 E395C531
left on device [root@test-server ~]# tail -f /var/log/maillog Nov 19 10:12:15 test-server postfix/postdrop...xvdb1 ext3 197G 18G 170G 10% /u01 5)腾出磁盘空间 比如将大文件剪贴到大分区下,然后再软链接回来;或者清空大日志文件 6)杀死所有sendmail和postdrop...sendmail | grep -v grep | awk -F" " '{print $2}' | xargs kill -9 [root@test-server ~]# ps -ef|grep postdrop...| grep -v grep | awk -F" " '{print $2}' | xargs kill -9 lsof再次查看,确保sendmail和postdrop进程数为0 [root@test-server...~]# lsof |grep sendmail |wc -l 0 [root@test-server ~]# lsof |grep postdrop |wc -l 0 7)最后启动sendmail,
数量超级大(具体值忘了),用VI编辑文件都有异常提示,系统几乎瘫痪 解决过程 决定先降低负载,好能正常操作,不然连输入命令都费劲,然后再找原因,从根解决 执行 top 时,在进程列表中看到了大量的 postdrop...进程,很明显这个有问题 先把他停了,让系统有个喘气的机会 #ps -ef|grep postdrop | grep -v grep | awk '{print "kill -9 " $2}' |...sh 看日志 找线索 /var/log 下,发下 maillog 文件很大、很新,和之前的嫌疑进程 postdrop 很符合 从 maillog 中发现大量的如下信息 Apr 21 16:56...:13 AY140 postfix/postdrop[2377]: warning: mail_queue_enter: create file maildrop/157768.2377: No space...在删除 maildrop 文件之前,复制出来了几个文件,内容都是一个命令的报错信息 再查看进程树 # pstree 发现是cron启动了sendmail,sendmail启动了postdrop
cron、sendmail、postdrop 最近有一台centos7服务器故障,经过排查发现是cron导致的,具体如下: 情景1:因cron错误触发sendmail进程发送告警邮件(没有配置邮件服务器...),邮件发送失败,进而触发postdrop进程,这个操作会不断累积,最终导致内存/innode号资源不足; 情景2:postdrop失败会有警告信息生成,保存在/var/spool/postfix/maildrop...,经过一段时间的累积,最终导致磁盘资源不足; fix情景1: 检查mem占用情况,发现大量的CRON——sendmail——postdrop进程; 先解决燃眉之急,直接pkill postdrop释放内存和...innode资源,但是几天后又出现同样的问题; why 有这么多的postdrop进程呢?
在其他分区创建空目录: // 杀死所有 sendmail 和 postdrop 进程 ps -e | grep sendmail | cut -d ' ' -f2 | xargs kill ps -e...| grep postdrop| cut -d ' ' -f2 | xargs kill mkdir -p /home/a.test rsync -av --delete /home/a.test/...head、tail 查看内容,发现全是同样的内容行,如下: May 2 5:29:23 lcha2 postfix/postdrop[1443]: warning: mail_queue_enter:...create file maildrop/383480.1443: No such file or directory May 2 5:29:23 lcha2 postfix/postdrop[1269...mail_queue_enter: create file maildrop/330426.1269: No such file or directory May 2 5:29:23 lcha2 postfix/postdrop
::1 也就是说 mail 提示无法为主机上 IPV6 的地址 ::1 发现对应的网卡 解决方法 注释掉 /etc/hosts 中 ::1 对应的地址后发现mail的错误信息变成了 postfix/postdrop...sudo mkfifo /var/spool/postfix/public/pickup sudo chown postfix:postdrop pickup systemctl restart postfix.service
使用rsync时空目录的路径后要带上"/" 追根溯源 在清理完文件后不久又有一次内存告警,检测发现有大量的“CRON、sendmail、postdrop”进程,同时还发现“/var/spool/postfix...既然定位到是cron惹的祸,那就先把“sendmail、postdrop”干掉,解决燃眉之急,然后查找解决方案吧,办法如下: 将/etc/crontab文件中MAILTO="root"改成MAILTO
,嫌一条条命令去执行有点麻烦就写成脚本文件去执行: yum remove postfix -y userdel postfix groupdel postdrop groupadd -g 2525 postfix...useradd -g postfix -u 2525 -s /sbin/nologin -M postfix groupadd -g 2526 postdrop useradd -g postdrop...-u 2526 -s /sbin/nologin -M postdrop 2.下载源码包并解压编译(如果下载地址失效就到官网去找下载连接): cd /usr/local/src/ wget http:...You can no longer specify "no" here. setgid_group: [postdrop] Please specify the final destination.../var/spool/postfix chown -R postfix:postdrop /var/lib/postfix/ chown root /var/spool/postfix chown -
服务器,在邮件服务器系统中充当MTA角色 1 安装Postfix (1) 创建相关的用户和组否则make install得时候会报错 #groupadd postfix -g 501 #groupadd postdrop...#useradd postfix -u 501 -g postfix -G postdrop (2) 解压安装 #tar -zxvf postfix-2.6.0.tar.gz #cd postfix
systemd-journal:x:190:systemd-bus-proxy:x:997:systemd-network:x:996:dbus:x:81:polkitd:x:995:dip:x:40:tss:x:59:postdrop...systemd-journal:x:190:systemd-bus-proxy:x:997:systemd-network:x:996:dbus:x:81:polkitd:x:995:dip:x:40:tss:x:59:postdrop...:: postdrop:!:: postfix:!:: sshd:!:: zero:!:: user1:!:: slocate:!
tom.com,yahoo.com,189.com,baidu.com,qq163.com sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop
colord:x:121: pulse:x:122: pulse-access:x:123: myths:x:1000: sambashare:x:124: ftp:x:125: postfix:x:126: postdrop
如:/tmp/empty是root:root,而maildrop之前是postfix:postdrop ,执行之后也会maildrop目录的权限也会变成root:root 。
ssh_keys:x:999: input:x:998: systemd-journal:x:190: systemd-network:x:192: dbus:x:81: polkitd:x:997: postdrop
sample_directory = /usr/share/doc/postfix-2.10.1/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop
postdrop: warning: uid=0: File too large sendmail: fatal: root(0): message file too big Error sending
wbpriv - 88 - - samba-common postfix 89 89 /var/spool/postfix /bin/true postfix postdrop
uid: 1001,gid: 1001 无 postdrop Postfix专用组 该组不能包含任何成员,包括前面的postfix虚拟帐号也不例外。...vmail [root@mail ~]# useradd -g 1001 -u 1001 -s /sbin/nologin -M vmail [root@mail ~]# groupadd -g 1002 postdrop
mail() 内部启动了 /usr/sbin/sendmail、/usr/sbin/postdrop 两个新进程,它就是我一直苦寻的函数(用相同的测试方式,还找到一个 imap_mail())。
领取专属 10元无门槛券
手把手带您无忧上云