it looks like an expired modx cache is getting rebuild when run.php is triggered via cron.
I am looking for a way to prevent this. There may be side effects regarding file locking when the cronjob runs on a different server, and I cannot find a reason why the cache needs to be rebuild at this time.
Hi @devumapp - what sort of caches are we talking about here? I don’t think scheduler manages any caches by itself…
@mhamstra: the modx file cache. it is getting rebuild (if expired) because run.php is calling ModX (via the API). And ModX performs cache related tasks when it is called. it seems to make no differences wether it as an actual visitor of a site or a cronjob calling a script.
“the modx file cache” is not very specific… that can literally mean any cache file
Indeed there are some caches that could get generated from the cron job if they expired/were removed, but the ones I can think of (system/context settings) don’t normally expire. I’m wondering if there’s something specific in your tasks that might be causing things to be removed/rebuilt/generated.
I don’t think there’s any way to prevent caches being updated. As you say, we’re just calling the MODX APIs which may load certain things from cache and regenerate it if those caches don’t exist/expired.
the caches that are rebuild are resources and releated elements. this is the expected behavior for a normal visitor triggering modx, I guess. The problem is that, when modx gets called from a cronjob on a different machine (in a multi server setup), this machine has different server paths etc., that are then used by ModX, but result in errors, since ModX is running on a different machine - we fixed this in our setup with adjusting the server configuration on the cronjob machine, which might always be the best solution. However, I was wondering if there might be a way to prevent this in the first place when calling the API, since it seems not really necessary at this point to trigger the cache management.