我们使用 postfix 和 sendmail 接口,并尝试使用 php mail() 函数发送邮件,但出现以下错误:
无法在 /var/www/html/xyz/temp.php 第 9 行执行邮件传递程序“/usr/sbin/sendmail -t -i”
/usr/sbin/sendmail 存在且具有执行权限
服务器是虚拟专用服务器:Linux 版本 2.6.9-023stab051.2-smp(root@rhel4-64)(gcc 版本 3.4.5 20051201(Red Hat 3.4.5-2))#1 SMP Thu Sep 24 22:32:27 MSD 2009
postfix 正在运行,我们可以通过 telnet localhost smtp 发送邮件
过去两年来它一直运行良好,但现在突然出现这个错误。
有一个类似的帖子,但是没有答案: 错误:无法执行邮件传送程序‘/usr/sbin/sendmail’
答案1
哦,在 PHP 中执行外部程序的能力突然发生了变化?听起来好像有人在共享主机上运行,而他们的托管提供商突然决定提高其服务器的安全性(可能是因为他们遭到了大规模攻击),并且没有告诉任何人(因为“这能破坏什么?”)。在这种情况下,您只能放弃,转而使用提供专业服务且不会随意改变的共享主机提供商。
不过,就您而言,这种可能性可能较小,因为您说您使用的是“虚拟专用服务器”(尽管这个扭曲的术语暗示了市场干扰,这绝不是一个好兆头)。但是,事实是“突然停止工作”让我们得出了同样的结论:有些东西已经发生了变化,而无论是谁做了改变,都没有先进行适当的测试。
因此,您要做的就是查看机器的变更管理历史记录,并确定问题发生时发生了什么变化。或者,由于您没有变更管理历史记录(这是一个假设,但我愿意为此打赌),您可以与拥有该机器 root 权限的每个人交谈,并询问他们做了什么(如果很多人都拥有 root 权限,那么就放弃并构建一个具有良好安全和管理策略的新机器)。
您还可以尝试通过查看包管理日志来缩小更改的范围(我思考RHEL4 记录了所有软件包的安装/升级,但我最后一次接触 RHEL4 是在两年前,现在我有点记不清了)、命令 shell 历史记录、sudo 日志(如果你真的很幸运的话)以及战略find -mtime -N
运行以查看哪些文件比你确定的服务故障时间范围更新。备份(假设你保留了存档备份,你可以当然应该进行配置)可以帮助准确识别发生了哪些更改。
一旦知道了更改的内容,就可以检查更改并尝试缩小出错的范围。任何与 PHP、MTA 或 Web 服务器有关的内容显然都是立即可以解决的问题,但不要这么快就忽略看似无害的更改 - 如果您不确定,请将其保留在“可能”列表中。然后,您将有一项有趣的工作,即尝试撤消更改,直到找到问题。这是一项艰苦而费力的工作,充满危险,如果有多个更改影响到问题,您可能会在那里待很长时间。
听起来很难?当然是。这就是为什么你一开始就做好工作(计划、测试、文档) 并且不要忽略细节。