Plesk Question posted in
The official documentation for Plesk Obsidian can be found here.

pdflush on port 80 preventing Apache from restarting – Plesk

Preliminaries:
+ CentOS 5
+ Plesk 10.4.4 Update #35

Problem: During the addition/alteration of a new domain/host in plesk, it will normally write new or update apache vhost config files and then restart the apache service. The updating rewriting seems to go fine, there are no errors in the files, however lately apache fails to restart after shutting down due to the unavailability of port 80, further examination via “netstat -tulpn…” shows the following…

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

You can see that PDFLUSH is occupying a high process ID but is sitting on both 80 and 443 which prevents apache from coming back up. I’m having to manually get the PID and issue a kill before I can run “service httpd start” again to get apache up.

In my searching, I’ve seen an old reference to someone being hacked but I can find any similar symptoms, and honestly I don’t know what to look for in the logs or which log file to look at specifically. I’ve also heard that this could be a symptom of failing memory but I don’t know how to test memory on a production server.

Please, any help would be greatly appreciated, my heart sinks every time I get an SMS that the servers down again!

EDIT
It’s happened again by simply adding a subdomain, however this time I was able to run a ps -aux quickly prior to killing the PDFLUSH instance and bringing back up apache…

apache … ./PDFLUSH -b service.config

Trying to search out the location of that now…

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    The good news is I found the culprit, the bad news is that it is "c99", just do a google on it and you'll find a long history. Now the real fun begins, has the server been rooted?

    For those that have similar issues and think it might be the same even if it's using a name other than "PDFLUSH", just do a

    find /var/www/vhosts -name PDFLUSH

    To figure out where the little bastard is hiding. I found mine in one of my shared hosting clients sites buried deep in a dir tree inside the webroot.


  2. 0

    The netstat output that you have included is highly suspect:

    • The program that you are seeing is called PDFLUSH with all characters in upper case. This seems like an attempt to evade detection; pdflush (all lower case) is the name of a legitimate kernel thread that handles writing dirty memory pages back to the disk. It highly unlikely that any legitimate program would be using such a name.

    • The legitimate pdflush does not have any networking capabilities – it has nothing to do with networking at all. This one seems to be acting as a web server, yet no web server with such a name exists. Unless you explicitly installed a custom web server with that unfortunate name, you have a problem.

      Have you tried connecting to those two ports with netcat or a Telnet client? That might give you a clue on what is going on.

    As far as testing the memory of your system goes, memtest86 is the de facto standard tool these days. Failing memory, though, usually appears in the form of random crashes – what you are seeing seems way too specific.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search