Running setup fixes a 2.2.10(adv) install for a few days only, then manager dies

I have a site running on 2.2.10(adv) with customized manager and connector directories and the core outside the root public_html. When I run setup the manager works fine, but only for a few days, then the manager breaks - the news panels load, but the document list on the left doesn't.

This has now happened a few times, each time running setup fixes the site for a few days then the problem reappears. I've tried manually deleting the cache, the problem still reappears. What else might be reappearing from the depths somewhere to cause the manager to lose something it needs?

Thanks and sorry for the numerous posts lately asking for help - I've built a bit of a business with many MODx sites, and have had a pretty catastrophic start to the year.

Who are you hosting with? Some cloud hosting companies have cloud configurations that Revo doesn't work well with.

I'll certainly name and shame if it turns out to be their fault/configuration, but reluctant to until I've confirmed as they are one of my favourite mid-price hosts and provide pretty good service and technical support, and a misinformed shaming here would be unfair even if I then correct myself later in the thread. They are not one of the big ones you're likely to have heard of, and the problems I'm posting on another thread here are with sites on a different (cheaper) hosting company. It has been pure coincidence that sites on both hosts have had simultaneous problems. We've been running MODx on this host's servers since MODx 0.9.5 without problem.

So I did a backup of all files and database while the document menu was not appearing, then ran setup and took another backup. The changes are:

1. Fully thirteen thousand records removed from the modx_session table. I had run setup only around 48 hours prior to this, so these (12,882) records accumulated in just that time (assuming setup truncates this table).

2. modx_actions_fields seem to have been regenerated (to the same again), AUTO_INCREMENT numbers increased, etc. (I also made a couple site_tmplvar_templates tweaks on an unrelated bug between captures.)

3. The timestamp and UIDs in config.inc.php, and a few other probably inconsequential changes such as my login count, for some reason my password hash, my action history, etc.

I didn't compare the cache or directories related to packages.

A couple example records:



Anyone any idea what might be causing these huge session record accumulations? (I'm assuming this is the likely cause but haven't yet proven it.)

I've the extras Provisioner, Gallery, Quip, VersionX, Batcher, FormIt, getPage, getResources, GoogleSitemap, Login and siblingNav installed, in case that is relevant.

I ran setup an hour or so before the office closed Friday evening and all manager activity would stop and there are 6,200 records in modx_session. As far as I can tell no-one has done any editing since before I ran setup, and probably no-one has logged into manager. I have rolled out the database on my local dev server with the 12,882 session records, and manager seems to work OK, suggesting either this is not the cause, or perhaps it is hitting a memory limit. I have asked my hosts for any errors from the Apache log.

Where are session records deleted? Perhaps I can start there and work backwards. [ed. note: technicaltitch last edited this post 10 years, 3 months ago.]

Edit: This is a red herring

The hosts sent the error log - any ideas?

example.com-error_log.1.gz:example.com [Fri Jan 17 05:04:24 2014] [error] [client 208.43.252.200:44399] AH01215: PHP Fatal error: Call to undefined method modX::getDocumentObject() in /home/sites/example.com/core/cache/includes/elements/modsnippet/40.include.cache.php on line 43

Unfortunately I didn't back up the cache directory before running setup, and as far as I can tell the number (40) doesn't relate to a snippet database ID. Any ideas how I diagnose this?
[ed. note: technicaltitch last edited this post 10 years, 3 months ago.]

Hm. That looks like your core class files aren't getting loaded. And that sounds suspiciously like your server paths are getting switched around. I've hear of hosts that do that.

Take a look at the config.core.php files (there are three of them, one in the root, one in the /connectors/ directory and one in /manager/) and see if the path in them matches the path in the phpinfo display in Reports -> System Info. Scroll down to near the bottom of the phpinfo display and look for $_SERVER["DOCUMENT_ROOT"] and $_SERVER["SCRIPT_FILENAME"]. The paths should be the same.

Great tip thanks. They are as you'd expect:

_SERVER["DOCUMENT_ROOT"] /home/sites/example.com/public_html/
_SERVER["CONTEXT_DOCUMENT_ROOT"] /home/sites/example.com/public_html/
_SERVER["SCRIPT_FILENAME"] /home/sites/example.com/public_html/phpinfo.php

(These are the only three mentions of the path in the phpinfo output - identical in both environment and server sections.)

I didn't get a copy of the root/config.core.php before re-running setup. I'd be very surprised if I didn't check these first, I'll grab this when it next happens, but the other two were set correctly to match the above (and when I diff'd every file before and after running setup these matched).

Perplexed on the error. I searched (recursively) for the string getDocumentObject in core/*.php and root/*.php, and find no instance or call to the method modX::getDocumentObject(), so where could that "fatal: call to undefined method modX::getDocumentObject" be coming from?
Edit: This was a red herring - my search (*.php) missed the database sql. getDocumentObject is called by a snippet on a couple pages so this is unrelated.

modx_session has added 5,000 records today having been relatively stable over the weekend with no MODx manager users. I increasingly suspect this is the issue even though there were no memory errors in the logs. I've been looking around the MODx docs about sessions and they seem synchronized with the PHP sessions. Given they'll time out without firing a MODx event, shouldn't there must be some sort of housekeeping that isn't happening on my site? [ed. note: technicaltitch last edited this post 10 years, 3 months ago.]

Quote from: technicaltitch at Jan 19, 2014, 01:15 PM

Where are session records deleted? Perhaps I can start there and work backwards.

Is your server running Ubuntu?
I vaguely remember reading about session table overflowing with default PHP Ubuntu installation somewhere on this forum...

Thanks for the tip. I'd be surprised if the hosts were running Ubuntu or the default installation - it's a pretty tightly configured and customized pseudo-CPanel environment. I've not been able to find the thread you remember, but my search taught me a bit more about sessions, and I have realized that only 16 of the 13,000 records are mgr context, and people have 60,000+ record session tables without problem, so the session table is likely to be another red herring, although I'll try truncating session next time the bug appears.

(For non-native speakers, by "red herring" I mean a distracting piece of information - this smoked fish was used by fugitives to put bloodhounds off their scent.)

I think I need to wait for it to happen again, then increase the PHP logging until I find the point at which manager dies. Given it is displaying part of the manager UI I reckon it must be finding core, and is failing later on. [ed. note: technicaltitch last edited this post 10 years, 3 months ago.]

13K sessions is a large number but shouldn't typically be an issue. If you want to keep the sessions down, you could disable the sessions in the web context. The downside of that is that manager users wont be able to preview unpublished resources, as it doesn't check the session at all, but it would keep the session table size down.

ALso, the $modx->getDocumentObject error you're seeing would actually be an issue. The getDocumentObject method was for Evo, and was removed in I think 2.1.0, so that results in a fatal error. What is the snippet that uses it (snippet 40)? And how are you referencing it in your templates?