1

预备：+ CentOS 5 + Plesk 10.4.4 更新 #35

问题：在 plesk 中添加/更改新域/主机期间，它通常会写入新的或更新 apache vhost 配置文件，然后重新启动 apache 服务。更新重写似乎很好，文件中没有错误，但是最近apache由于端口80不可用而在关闭后无法重新启动，通过“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

现在正在努力寻找它的位置...

4

2 回答 2

1

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

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

查找 /var/www/vhosts -name PDFLUSH

想知道这个小混蛋藏在哪里。我在我的一个共享托管客户端站点中找到了我的站点，该站点深埋在 webroot 内的目录树中。

于 2012-07-10T16:30:45.677 回答
0

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

  • 您看到的程序PDFLUSH以大写的所有字符调用。这似乎是一种逃避检测的尝试；pdflush（全部小写）是处理将脏内存页写回磁盘的合法内核线程的名称。任何合法程序都不太可能使用这样的名称。

  • 合法的pdflush没有任何网络功能 - 它与网络无关。这似乎是作为一个 Web 服务器，但不存在具有这样名称的 Web 服务器。除非你用那个不幸的名字明确地安装了一个自定义的 Web 服务器，否则你就会遇到问题。

    您是否尝试过netcat使用 Telnet 客户端连接到这两个端口？这可能会给你一个关于正在发生的事情的线索。

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

于 2012-07-05T23:48:45.620 回答