HELP! Modx core is spawning hundreds of requests to php.ini and taken down our server!!!

Hi Running Modx revo 2.2.2pl on a VPS environment.

Got a call today from our hosts saying that something in the core folder of one of our Modx install is spawning hundreds of commands to one of the php ini files and its creating loads of PHP instances.

We are running fast cgi as the PHP handler and the Modx site in question has multiple contexts set up in it.

The mystery command being fired is below:

13965 ***USER HERE*** 15 0 167m 10m 6636 S 0 0.1 0:00.38 /usr/bin/php5-cgi -c /var/www/vhosts/OURDOMAIN.com/etc/php.ini

I have searched and not found anyone reporting anything similar.

Am current searching the core folder for anything suspicious.

But our site is still offline still and our CEO is really not happy!!

Anyone have any suggestion for either things to try / similar experiences / debugging options ??

Any help appreciated!!!

Anything in the MODX error log?

I had a site do something similar once, it ate 12gb of bandwidth in something like 8 hours. the autoFixImageSize extra, which I wasn't using so I x'd it and bookmarkThis which solved the constant requests to the server.

Does your cache rebuild itself as soon as you clear it?

Hi Frogabog, thanks for the feedback its useful to know.

With regards to cache - its a little unclear our marketing department had managed to generate a couple of resources with duplicate aliases - which was producing an error on 'clear cache' but it wasn't obvious if that was making the cache clearing fail - I guess not.

Just realised that I had admitted to mention that we had just sent out a bulk email to quite a few people but that still wasn't generating more that 40 / 50 concurrent visitors to our site according to Google Analytic's prior to the crash. Which ultimately is nothing.

Anyhow we got the host to enable our vhost and as mentioned we are running php as fast CGI and a colleague tweaked some of the settings and it seemed that this lessened the load on the server and it still up an running.

That all said I am interested about how the plugins you mentioned were firing continual requests to the server.

I am still playing and if find out anything else more I will post back.

Thanks for your time.

I haven't used autoFixImageSize since, but BookmarkThis hasn't caused a problem in any other installs. I am skeered of autoFixImageSize. It's like a forbidden fruit, I want to try it but I don't dare do anything but pick it and leave in a bowl on the table. [ed. note: frogabog last edited this post 14 years ago.]

Could you tell us more about the site such as what plugins you do have installed?

Got a call today from our hosts saying that something in the core folder of one of our Modx install is spawning hundreds of commands to one of the php ini files and its creating loads of PHP instances.

Were they be a bit more specific than "something in the core folder", by any chance?

I can't imagine anything in the MODX core or Extras would be directly target a php.ini file for anything, so I'm wondering if something malicious might have been placed there.

Some servers have .shtml files for handing 404s and similar requests. Things can get wacky sometimes if you're running MODX in a subdirectory and they're missing. See if there are is a set of ###.shtml files in public_html (or above it). If so, copy them to the MODX root directory.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Thanks all.

A little more info the command being fired was on further inspection seems to be calling up new instances of PHP rather that calling the php.ini file as the hosting support guy suggested - I think the php.ini call was just a parameter.



We had just sent out a bulk email prior the cpu overload. It was to quite a few people BUT my colleague who was monitoring the site on Google Analytics at the time said there was only 25 approx people on the site just before it went down.

@ AMD Builder - the site has 4 context running one with the translation plugin Bable running. Its revo 2.2.2pl. The site has been running for a good number of months (and been sending bulk emails relating to it from a reputable ESP) with no real problems. Sometime ago we tweaked a few of the fast cgi settings to allow for bigger file uploads etc but have not really done any other mods. The plugins we have installed are

Archivist
Articles
Babel
Batcher
Big Brother
FormIt
Gallery
getPage
getResources
GoogleSiteMap
If
ImportX
PackMan
Provisioner
Quip
Redirector
SuperCache
tagLister
TinyMCE
Wayfinder

@MarkH - That was the first thing I asked! Unfortunately the support guy that phoned me seemed somewhat junior. He said by a process of elimination they had singled out the core directory but that obviously contains hundreds of files....I am still chasing them for something more concrete.

@Bob - I haven't seen any .shtml files. We are running modx in the root.

I am getting a feeling that the server config that came out of the box inst great my colleague tweaked a couple of the fast cgi settings shortly afterward the overload to reduce max script execution time / time to live / concurrent processes and it seem to reduce the general load but I am still not really in a position where I feel happy with it all.

Don't really have much else to go on - but am trying to push the host to provide exactly which script was causing the new instances of PHP. And if there isnt get them to turn on some form of logging that might capture such activity in the future.

Anyone have any last thoughts? and again thanks for your suggestions so far.

This is entirely a server environment problem and has nothing to do with MODX. PHP code does not specifically call out to php.ini, ever. This is part of the CGI configuration with the web server and is the responsibility of your hosting provider.

@Opengeek thanks for the feedback. We had pretty much come round to that way of thinking. We discovered that we might not be running the best fastcgi settings on our server which may well have contributed to our woes.

A colleague read up and changed a number of them and so far we seem good.

Thanks all.

PS anyone who stumbles across this these were two very helpful fastcgi links.

https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html