Hi everyone,
Has anyone had a similar issue with the cache-purge job id showing a status of Failure, and found the reason for it?
There is noting in the error logs and the other schedulers show status of Success.
Looking forward to your replies.
Hi everyone,
Has anyone had a similar issue with the cache-purge job id showing a status of Failure, and found the reason for it?
There is noting in the error logs and the other schedulers show status of Success.
Looking forward to your replies.
This remains a mystery to me.
I have been having problems with the Grav Cache System since the last update. 4 Grav installs that have been running for over 12 months with no problems prior to the last update.
To keep the sites up I have had to run via cron outside of Grav “bin/grav cache --all” every hour. The admin login still becomes inaccessible in less than an hour, occasionally. Since I set the scheduler for automated backups, via setting up cron, red messages says “cron not available”. Yet the backups run, but the cache-purge & cache-clear do not. I have had to turn the cache-purge & cache-clear off or the backup will not run.
I have other backup methods and will probably simply turn off the automated backups via Grav. To see if the scheduled cache-purge & cache-clear will run and alleviate the need to run via cron bin/grav cache --all every hour.
I have been waiting to see if there are any other post’s in the forums, wondering if I am the only one having cache problems.
I tried running cache off a Redis server yesterday. But same problem and even more today, pics will not load. I had to turn of cache completely and leave Redis off to get pics to load.
I run Haproxy for ssl termination and Varnish Cache in front to the webservers (nginx). I have a cluster setup for redundancy & performance. Utilizing Amazon AWS. I only run VPS’s, I do not use the Amazon AWS cache services. It is cheaper & faster to run Haproxy & Varnish Cache on a vps.
Since I do run Varnish, I really do not need to run the Grav cache, but every bit of cache does help in over all performance especially so with high loads of concurrent connections. I am to the point I am going to simply turn the Grav Cache off. Until some kind of fix comes along.
I use Zabbix for monitoring the websites so I know immediately when I need to get in and manually run “bin/grav cache --all”, if things lock up prior to the every hour cron job.
I have not spent much time looking into what is causing the cache problems, nothing in the logs points to a problem. All I know is everything worked fine until the last update.
This sounds different to my problem. I have a few sites running grav now but 1 gives the cache-purge error and nothing in the logs.
I figured it was probably different. Not really any other threads on cache problems. Since no one had replied, thought I would throw out what I am encountering just to see if you or anyone else has experienced the same, or just get more stuff added to aid in searches.
Perhaps some thing will turn up eventually. Since I have not changed any settings, php, nginx or grav. It may not have anything to do with grav, as there does not seem to be any others with the same issues.
It may be an issue with a PHP update, last update to php was March 12. Amazon AWS is not exactly timely with updates, and getting up to date with most current stable releases. Their Amazon Linux 2 ami is an improvement with their addition of their amazon-linux-extras, which has more recent releases.
Yet they are only on PHP 7.3.13. I am on 7.4.5 on my Gentoo boxes, though PHP 7.3.17 is marked stable for 7.3 versions in Gentoo. Amazon always behind. Amazon-linux-extras has 7.4 listed, but does not list full version. I might install their 7.4 version on a test server, just to see if that changes anything.
Since things did not work the way it should when I switched to Redis, it may be some php bug. Redis works fine on my Gentoo dev boxes with no issues. I just need to take the time and try out a few variations. Since no-one else seems to be having issues, it most probably is not Grav.
I also noticed this that using the purge cache option returns an error. But isn’t this related to the fact that Redis caching doesn’t use files? It’s in-memory caching.
So this error DirectoryIterator::__construct(/var/www/vhosts/grav/cache/doctrine):
makes sense then, right? Because Redis doesn’t use the file system for caching.
The error is confusing, I agree. Maybe you should file a bug report?