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
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
$ 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
在其他分区创建空目录： // 杀死所有 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
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进程呢？
::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元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
