All Grav sites broken - InvalidArgumentException cache directory not writable, but it is

@Vince42, I’ve taken a look at the stacktrace again, but now at the right side of it.

Here are a few of the variables of $_SERVER shown in the stacktrace:

REQUEST_URI: /admin/dashboard
REDIRECT_URL: /admin/dashboard

HTTP_REFERER: https://all24.net/admin/plugins

SCRIPT_URI: https://all24.net/admin/dashboard
SCRIPT_URL: admin/dashboard

REDIRECT_SCRIPT_URI: https://all24.net/admin/dashboard
REDIRECT_SCRIPT_URL: /admin/dashboard

I’m surprised to find a reference to above Admin urls:

  • Apparently, the site crashes when accessing Admin.
  • Any idea why these pages are being accessed?
  • Is there any process that requests these pages regularly?
  • What will happen when you remove Admin plugin from //all24.net?

Increasing cache/doctrine:

  • When running find cache/doctrine -type f | wc -l, after each page request to ‘/admin/dashboard’, it shows an increase in the number of files in the cache/doctrine folder. Not by much (4 files), but if it happens often…
    A login costs another 4 files extra.
  • Requesting a normal front-end page, which has already been cached, does not create any new file in the cache folder.

Update:
Only later I realised that the pages mentioned above are probably accessed by yourself to show the stacktrace… Oh well…

@pamtbaau, The reason, why the admin is shown in the stacktrace is, that the main site were still operating (maybe just delivering a still valid cache content), while the login into the admin area were already broken due to the exceeded quota (at least that is my interpretation for that behaviour).

  • Correct.
  • I accessed them in order to produce the crash and the stacktrace.
  • No, that is just me, when I try to login.
  • I think it would be pointless to remove the admin plugin, as the site filled the cache without any interaction. In other words: I cleared the cache, let the site alone for five days, received quote warnings, tried to login in order to clear the cache and the admin login attempt resultet in a crash and the stacktrace.

Hmmm … interesting point worth to scrutinize. I could check the web logs, how often the admin page is visited.

But aside from that effect: Shouldn’t the automatic cache clear routine clear the cache every x hours anyway? From my understanding, the 2 GB of cache files are not filled during the time span between two automatic cache clearings; in fact it seems, that the cache clearing does never happen, which leads to the exceeded quota after five days.

Nevermind, it is still possible that something is calling the admin page on a regular basis. I will check that on next occasion.

Let’s focus on the automatic cache clearing.

  • Purge is scheduled at 4:00 every day.
  • Clear is scheduled at 3:00 every day.

Maybe I should check, whether the cron jobs even exist and are run on a daily basis. I checked /etc/cron.daily and were not able to find anything named “grav”. Where are the cron jobs stored and invoked?

And one mystery remains: This site is currently the only one flooding itself with cache files. It really seems that there is to few content - LOL. Any idea how this could be possible? I am already prone to give the site some content and to re-observe its behaviour.