Home/ Questions/Q 8214693
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T11:32:34+00:00

Preliminaries: + CentOS 5 + Plesk 10.4.4 Update #35 Problem: During the addition/alteration of

  • 0

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…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0