Error when emtying cache after update from 8.5.x to 9.2.9

Developing with Concrete
1

We’re in the process of converting a couple older sites 8.5.xx to version 9.2.9. Most of the time everything runs without a hick.

With some sites though I experience an error emtying cache. It won’t let me do that. I have the following error:

Symfony \ Component \ Messenger \ Exception \ HandlerFailedException (2)

Handling “Concrete\Core\Cache\Command\ClearCacheCommand” failed: include(www/xyz.com/application/files/cache/expensive/0fea6a13c52b4d47/25368f24b045ca84/38a865804f8fdcb6/57cd99682e939275/3e7d68124ace5663/5a578007c2573b03/736abbd0621df6ef/08874cec99a4cc06.php) : Failed to open stream: No such file or directory

When I emty manually the cache in application/files/cache/ the error persists.

The site runs fine online and is not affected.

Do I have to look into the database if there are some reminiscence of the older system? How can I find out.

Hints greatly appreciated.

2

I don’t have a great deal of knowledge here but I think you’re on the right path as far as checking the database. I did a grep of the related code and I can see that there are file paths stored in the database that are supposed to be cleared out:

[user@s1]$ grep -A5 "Database" concrete/src/Cache/Command/ClearCacheCommandHandler.php | tail -10
--
    private function clearDatabaseCache()
    {
        $connection = $this->manager->connection();
        $sql = $connection->getDatabasePlatform()->getTruncateTableSQL('FileImageThumbnailPaths');
        try {
            $connection->executeUpdate($sql);
        } catch (Exception $e) {
        }
    }

I believe it is likely that for whatever reason some file paths are still lingering in the database, and concrete thinks that the files still exist on the filesystem.

The easiest way to do that would be to use the Search feature in PHPMyAdmin if that’s available to you. Otherwise make a mysql dump of the database and then use grep on the resulting sql file.

EDIT
I also just remembered that you can run into this type of problem if your server’s disks are failing. Sometimes a file can ghost if the disks are going bad.

My recommendation is to take this as a serious warning to double check the health of your disks as soon as you can.
Some commands that you could use to start looking into this on RHEL style system:

grep "\-fs" /var/log/messages
dmesg | grep "\-fs"
journalctl -b | grep "\-fs"

If you’re stuck or not sure what to do but you have concerns about your disks you can DM me questions.

3

Thanks @alcopros,
I will pass this information to our database specialist to do the suggested database searches.

I found out, that when logged in as the admin user, there were different missing files when trying to empty cache.

It’s not the problem of server disk health.

1 Like
4

I’ve seen countless servers where random files will start to ghost during disk issues, especially cache files since they’re written and removed often. I trust that you know what you’re looking at when you say you’re sure there are no disk issues, but if you’re not 100% positive it is definitely worth it to double check. Unless you have backups and you have a backup restoration plan that you’re confident in.

5

Is this a high availability setup? Are you using redis or some other caching layer for the application cache?

6

Thanks for responding. Sites are hosted on regular solid webhosting. No Redis, no caching. Issue still not resolved.

7

When you say “emty manually the cache in application/files/cache/”, do you mean you use rm -r application/files/cache/*, or that you used the CLI command. Just for grins, you might want to try this from the command line:

./concrete/bin/concrete c5:clear-cache

I just ran this on the latest v9.x version and it works fine, although I don’t have the issue that you do.

Dave

8

I emptied the cache first via dashboard then “manually” without CLI, just deleted all files in the cache.

We also tried @alcopros suggestion to look into the database. There were no files or file paths with that name.

We finally created PHP file named the same as in the error msg and recreated the same folder structure and moved into the cache.

After emptying the cache via dasboard it emptied now without error.

Thank you all for help.
Though I still don’t know what the file was or why it was there.

1 Like