Root-Cron and cache refresh

Hi @all,

I'm dealing with an issue regarding a cron job based refreshing of system settings. I know it's not the best practice to run cron as root, but currently there is no other way because I have to move and unlink files of another user.
When running this cron I need to refresh system settings, which is done by
This recreates some partitions correctly, but destroys for example our static files cache by setting root as owner and group.

I'm not that good with ACL's, but would a corrected ACL-rule maybe help solving the problem?
Or is there a way to tell MODx CacheManager to force my apache-user to be the owner of these files?
Any help is really appreciated.

Thanks! [ed. note: herooutoftime last edited this post 13 years, 6 months ago.]

We've also stumbled onto this problem in the past, but since our program was running via CLI, we simply assumed (su - switched user) via SSH and did the command via the user. Not a good solution though, I get that.
Seeing that you are running at as root, can you try:



Give that a go, perhaps it does the trick.

I may be misunderstanding your question, but you can tell refresh to only clear certain parts of the cache. Some examples here:

http://rtfm.modx.com/display/revolution20/Caching#Caching-UsingmodCacheManager%3A%3Arefresh%28%29%28forMODX2.1andlater%29

Hi BobRay,

thanks for your reply.
I'm aware of that. The original call causing this issue was this:


The project relies on elements which are all served as static files. Problem is that this 'refresh' also recreates cache-partitions in cache/includes (static elements?) which get the CLI user owner & group permissions.

If the refresh syntax is correct: Why is the includes folder being recreated?

Thanks

I'm not sure, but some of the refresh options cascade. A quick look at the code suggest that it shouldn't happen.

This is the only code I could find in refresh() that would do that:

case 'scripts':
/* clean the configurable source cache and remove the include files */
$results[$partition] = $this->clean($partOptions);
$this->deleteTree($this->getCachePath() . 'includes/');
break;

And you're not setting 'scripts'.

You could use unlink to delete just that cache, but I'm not sure what the side-effects might be.

We ended up by just removing the config.cache.php via XPDOCacheManager->deleteTree(), which is fine for now, but...

It's bad practice because it's only working in a file-based cache system as opengeek pointed out: https://forums.modx.com/thread/25157/revolution-cache-browser-manager-selective-cache-clearance?page=2#dis-post-415696

I'm just wondering on this one as I didn't expected it to have such an impact, which it actually had and it's the needle in a pretty big haystack to find

@BobRay,

I was wrong. It wasn't refresh (not directly) which caused this issue. I tried to track it down and up to now my best guess is:
Am I right in assuming that 'OnDocFormSave' (or any other event) refreshes the major cache partitions? If so, this would be the explanation...

@ReSpawn: Your solutions works as expected. Thanks!

That would only be the case if some other plugin attached to an event refreshes the cache. None of the MODX events do anything at all unless a plugin is attached to them.

Saving a document does refresh the cache, but it has nothing to do with the events invoked.