端口80上的pdflush阻止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。

在我的搜索中，我看到了关于被黑客入侵的旧参考，但是我可以找到任何类似的症状，老实说，我不知道要在日志中查找什么内容或要专门查看哪个日志文件。 我还听说这可能是内存故障的征兆，但是我不知道如何在生产服务器上测试内存。

拜托，任何帮助将不胜感激，每当我收到一条再次使服务器宕机的短信时，我的心都会沉浸其中！

---

编辑它只是通过添加一个子域而再次发生，但是这次我能够在杀死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已成为事实上的标准工具。 但是，失败的内存通常以随机崩溃的形式出现-您所看到的似乎太具体了。