Laravel 5.4 - php artisan cache:clear does not clear cache files when using 'file' cache driver
Asked Answered
L

6

30

Laravel 5.4 app. CACHE_DRIVER is set to file and QUEUE_DRIVER is set to sync in .env.

When I run php artisan cache:clear It says Cache cleared successfully yet I still have 236K of files in my storage/framework/cache directory.

Frustrated by this, I also manually deleted all files/directories under storage/framework/cache using rm -rf * from that directory.

Now, when I run art queue:restart I get [ErrorException] file_put_contents(/var/www/vhosts/my-app.com/releases/28/storage/framework/cache/ee/2f/ee2f842aa7bb1f53ed
f3a2ed2c09a1807ffa6c90): failed to open stream: No such file or directory

So, I have two problems on my hands. First is: why aren't all the cache files deleted by Artisan? How do I safely delete them? Second problem is: how do I recover from this so that php artisan queue:restart doesn't error out on me?

UPDATE: It occurred to me that I probably have no reason to restart a queue worker if QUEUE_DRIVER is set to sync, so skipping that command altogether resolves half my issue. Still not sure how to properly delete those 236K of cache files though.

Lawn answered 7/8, 2017 at 21:12 Comment(1)
did you manage to find out a solution? i am facing same issue and no luckTechnician
C
20

Update Jan 2020

Seems there is an easy solution to all of this. Using this answer https://serverfault.com/a/96349 as a reference, you can set the gid bit on the parent folder so that all subsequent files & folders created under ./storage/* are writable by anyone in the correct group regardless of who created them; thereby overcoming the group security permission issues as explained below.

This works for me:

# Assumes all required users belong to the www-data group
sudo chgrp -R www-data /path/to/storage

sudo chmod g+s /path/to/storage

Short answer

Use sudo: sudo rm -r ./storage/framework/cache

Long answer

Make sure all processes writing to the cache use the same user (and not just belong to the same group) because it turns out that Laravel writes cache files with privileges something along the lines of 0755 which restricts writes to the owner.

If like me you use a different user for each of these:

  • PHP process
  • Artisan CLI
  • Artisan via supervisor (for jobs)

You end up with files that belong to different users and cannot be written to or deleted by the other users even if they belong to the required group (www-data as an example).

Hopefully someone can find a way to set new cache file privileges in Larvel to something like 0775. It would be nice if it just inherited from the parent.

Side note

This for me was also causing a problem with Cache::remember() between the supervisor process & the PHP process such that I was getting put_file_contents errors because the cached files couldn't be written to by the different users.

Original answer

I was having the same problem and in my case the files weren't being deleted because they were write protected. When I went to delete them manually using rm -r ./storage/framework/cache I got the warning rm: descend into write-protected directory 'cache/c5'?. I wasn't going to type yes for every file in the cache so I ran the same command as sudo & it worked without a hitch sudo rm -r ./storage/framework/cache.

This answers your question as to why they aren't being deleted by Artisan cache:clear & running rm is an easy enough work-around; although it doesn't solve the problem of why the files are being written as write-protected.

After deleting the cache Laravel again creates the cache as write-protected. This means it is probably a bug & requires someone to submit a bug report to the Laravel developers. Since the work-around is trivial I'll leave that for someone else to do.

Counsel answered 24/11, 2017 at 17:22 Comment(5)
Just manually removing these doesn't break anything? Is this all that cache:clear does, delete all these cache files?Kerr
Seems to work, thanks! Although strange, clearing cache with cache:clear works locally but not on production =/Kerr
@Kerr From what I have read & as far as I am aware all cache:clear does is delete cached files. As to your second point, you might be a member of sudo locally?Counsel
Looking into Illuminate\Cache\FileStore.php, what's happening in case of a flush is that every directory below framework/cache/data gets deleted. Therefore, I'm using rm -rf framework/cache/data/*, which also prevents the .gitignore inside cache folder from being removed.Bangalore
A note - doing the short answer can sometimes cause problems with deleted .gitignore files. If possible, I much prefer and find it safer to just do sudo php artisan cache:clear if it's a permissions issue.Askari
E
14

You can try:

php artisan config:cache

It solve most of my problems.

Expiable answered 8/8, 2017 at 0:51 Comment(2)
Thanks, but no luck here. Did not resolve the issue.Lawn
There are several caches in Laravel & config:cache only clears & caches the application config files. The cache files created by the Cache::remember() method is what cache:clear should be clearing. config:cache isn't relevant to OPs problem.Counsel
R
4

You can also use Tinker:

php artisan tinker
Cache::store("file")->flush()
Roach answered 13/2, 2020 at 21:20 Comment(0)
E
2

I ran into similar issue recently. The cache files created through Cache facade seems to persist even after running php artisan cache:clear and as mentioned by @Precastic, is turned out to be a file permission issue.

Instead of removing the files/folders manually, I just ran the same command with admin privilege like this

sudo php artisan cache:clear

and it worked for me. Hope this helps someone.

Epilogue answered 12/2, 2020 at 7:30 Comment(0)
M
0

stop your server then run this php artisan cache:forget key

Makeyevka answered 22/12, 2023 at 4:27 Comment(0)
V
0

if you mean refreshing cache of a specific js library attached to the blade (or to it's parent or including) change script's source version , for instance :

<script src="{{ asset('assets/my_marker.js',false)}}?v=8"></script>

where v=8 was v=7 earlier and reload the webpage

Vial answered 16/3, 2024 at 15:2 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.