Strange Caching issue

Checked error log again and this is what I've got.

[Fri Aug 23 19:50:45 2013] [0000] [fcgid:warn] (104)Connection reset by peer: [client 00.00.00.00:000] mod_fcgid: error reading data from FastCGI server, referer http://www.website.com/
[Fri Aug 23 19:50:45 2013] [0000] [core:error] [client 00.00.00.00:000] End of script output before headers: index.php, referer http://www.website.com/
[Sat Aug 24 01:46:21 2013] [0000] [fcgid:warn] [client 00.00.00.00:000] mod_fcgid: read data timeout in 120 seconds
[Sat Aug 24 01:46:21 2013] [0000] [core:error] [client 00.00.00.00:000] End of script output before headers: index.php

I Think these are all related to the problem, but I don't really know what they mean.

I would do this: go through your core/cache files and figure out which one is getting poisoned. Usually that will tip you off as to which snippet or plugin (or???) is causing a problem. Your PHP logs should also be a good help for this.

If you have shell access, then "php -l" is your friend -- you can see which file has bad syntax.

Here's a code snippet you can use to iterate over all PHP files in a directory:



Hope that helps you track down the problematic code.

check_php_syntax() was removed in PHP 5.0.4, so it won't work if the version is later than that.

In that case, the next thing to do is probably to disable all plugins and bring them back one-by-one until it starts happening again.

Does deleting all files in the core/cache directory always fix it? If not, it's probably not a cache issue.

Quote from: BobRay at Aug 24, 2013, 04:03 PM

Does deleting all files in the core/cache directory always fix it? If not, it's probably not a cache issue.

Yes it always brings it back like nothing happened.

Everett, I ran your script and it didn't bring up any syntax errors. I ran it on pretty much all directories.

I have had errors pop up indicating fastField, but I have this on all my modx installs. I may try removing that and seeing if I get any results.

Did any of those server logged errors mean anything to anyone?

You would have to run the script after your site had crashed and BEFORE you clear the cache, otherwise, you're not doing anything useful with it. The file that barfs will tell you where the problem is. If you're not having a problem, then that script will do absolutely nothing for you. Does that make sense?

Quote from: Everettg_99 at Aug 24, 2013, 05:38 PM

You would have to run the script after your site had crashed and BEFORE you clear the cache, otherwise, you're not doing anything useful with it. The file that barfs will tell you where the problem is. If you're not having a problem, then that script will do absolutely nothing for you. Does that make sense?

Yes that makes sense but I can't see anything when the site crashes. Everything goes white.

I'm starting to think fastfield may have something to do with it. I removed all calls to fastfield and the plugin. When I remove the package the site goes down with this error:

Fatal error: Call to a member function parseProperties() on a non-object in /core/model/modx/modelement.class.php on line 535

Seems like it may have intertwined itself in the structure of the site.

When the site crashes is the ONLY time when you can do forensics. You'd run that script there from the command line completely separately from MODX. That's the only way to get any useful info from your cache files. Your PHP logs will probably point to the culprit too.

You can't easily remove the package: there's still a reference to it in the database, so it's looking for it and trying to call a method on it and ending up with that error about a non-object.

When you remove a plugin manually, it remains in the cache. It continues to fire and usually crashes when it can't find its files.

As Everett suggests, you should always uninstall the package in Package Manager rather than deleting it, then clear the cache for good measure, although simply right-clicking on the plugin in the Elements tree and disabling it generally has the same effect.

Quote from: BobRay at Aug 24, 2013, 11:50 PM

When you remove a plugin manually, it remains in the cache. It continues to fire and usually crashes when it can't find its files.

As Everett suggests, you should always uninstall the package in Package Manager rather than deleting it, then clear the cache for good measure, although simply right-clicking on the plugin in the Elements tree and disabling it generally has the same effect.

Yes, these are the steps I took. I first uninstalled via package manager. Then proceeded to remove the plugin. The steps I always take when removing a plugin and that is what happened.

Here is an update, however. After removing any references to the fastfield plugin - IE [[#2.tv.whatever]]. The site did not crash over night as it has everyday since installing and reinstalling modx on it. I'm convinced it had/has something to do with fastfield.

Very odd and disappointing, it is one of my go to plugins. I can just do a custom snippet to get around it, but it is very odd. If anything changes I'll report back.

Thank you BobRay and Everett if it crashes again I'll try and run that syntax snippet.

I noticed this in the fastfield plugin docs:

MODX uses modParser class for parsing default tags. This plugin adds class fastFieldParser that extends modParser. So, if modParser is modified in new version of MODX, the behaviour of plugin will be unpredictable.

Creating a whole new, second MODX parser object seems a little risky to me and also overkill for what this does. A dedicated snippet seems like a better option, imo. [ed. note: BobRay last edited this post 13 years, 1 month ago.]