pdflush在端口80上阻止Apache重启

Question

预赛： + CentOS 5 + Plesk 10.4.4更新＃35

问题：在plesk中添加/更改新域/主机期间，它通常会编写新的或更新apache vhost配置文件，然后重新启动apache服务。更新重写似乎没问题，文件中没有错误，但是最近由于端口80不可用而关闭后apache无法重启，通过“netstat -tulpn ...”进一步检查显示以下内容......

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 :::80                       :::*                        LISTEN      25794/PDFLUSH
tcp        0      0 :::443                      :::*                        LISTEN      25794/PDFLUSH

你可以看到PDFLUSH占用了一个高进程ID，但是它位于80和443上，这阻止了apache重新启动。我不得不手动获取PID并发出一个kill，然后再次运行“service httpd start”以获得apache。

在我的搜索中，我看到一个旧的引用被黑客攻击，但我可以找到任何类似的症状，老实说，我不知道在日志中查找什么或具体查看哪个日志文件。我也听说这可能是内存失败的症状，但我不知道如何在生产服务器上测试内存。

拜托，非常感谢任何帮助，每当我收到短信服务器再次关闭时，我的心就会下沉！

---

EDIT 只需添加一个子域就可以了，但是这次我能够在杀死PDFLUSH实例并重新启动apache之前快速运行ps -aux ...

  

apache ... ./PDFLUSH -b service.config

现在试着找出那个位置......

Answer 1

好消息是我找到了罪魁祸首，坏消息是它是“c99”，只是在谷歌上做它你会发现很长的历史。现在真正的乐趣开始了，服务器已经扎根了吗？

对于那些有类似问题并认为即使使用“PDFLUSH”以外的名称也可能相同的人，只需做一个

  

查找/ var / www / vhosts -name PDFLUSH

弄清楚这个小混蛋隐藏在哪里。我在我的一个共享托管客户网站中找到了我的网站，这些网站深埋在webroot内的一棵目录树中。

Answer 2

您所包含的netstat输出非常可疑：

• 您看到的程序名为PDFLUSH，所有字符均为大写。这似乎是企图逃避侦查; pdflush（全部小写）是合法内核线程的名称，用于处理将脏内存页写回磁盘。任何合法程序都不太可能使用这样的名称。

• 合法pdflush没有任何网络功能 - 它根本与网络无关。这个似乎充当了Web服务器，但是不存在具有这种名称的Web服务器。除非您明确安装了具有该不幸名称的自定义Web服务器，否则您会遇到问题。

  您是否尝试使用netcat或Telnet客户端连接这两个端口？这可能会让你知道发生了什么。

就测试系统内存而言，memtest86是目前事实上的标准工具。然而，失败的记忆通常以随机崩溃的形式出现 - 你所看到的似乎过于具体。