Laravel 5.4 - cache artisan php: clear n'efface pas les fichiers cache lors de l'utilisation du pilote de cache 'file'
Laravel 5.4 app. CACHE_DRIVER est défini sur file et QUEUE_DRIVER est défini sur sync dans .env.
Quand je lance php artisan cache:clear Ça dit Cache cleared successfully pourtant j'ai encore 236K de fichiers dans mon storage/framework/cache répertoire.
Frustré par cela, j'ai également supprimé manuellement tous les fichiers/répertoires sous storage/framework/cache en utilisant rm -rf * à partir de ce répertoire.
Maintenant, quand je lance art queue:restart Je reçois [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
Donc, j'ai deux problèmes sur mes mains. La première est: pourquoi tous les fichiers de cache ne sont-ils pas supprimés par Artisan? Comment les supprimer en toute sécurité? Le deuxième problème est le suivant: comment puis-je m'en remettre afin que php artisan queue:restart ne me trompe pas?
MISE À JOUR: Il m'est venu à l'esprit que je n'ai probablement aucune raison de redémarrer un travailleur de file d'attente si QUEUE_DRIVER est défini sur sync, donc ignorer cette commande résout complètement la moitié de mon problème. Je ne sais toujours pas comment supprimer correctement ces 236 Ko de fichiers de cache.
Réponse courte
Utilisez Sudo: Sudo rm -r ./storage/framework/cache
Longue réponse
Assurez-vous que tous les processus qui écrivent dans le cache utilisent le même utilisateur (et n'appartiennent pas seulement au même groupe) car il s'avère que Laravel écrit les fichiers de cache avec des privilèges quelque chose comme 0755, ce qui restreint écrit au propriétaire.
Si comme moi, vous utilisez un utilisateur différent pour chacun d'eux:
- Processus PHP
- CLI artisanal
- Artisan via superviseur (pour les emplois)
Vous vous retrouvez avec des fichiers qui appartiennent à différents utilisateurs et ne peuvent pas être écrits ou supprimés par les autres utilisateurs même s'ils appartiennent au groupe requis (www-data comme exemple).
Espérons que quelqu'un puisse trouver un moyen de définir de nouveaux privilèges de fichier cache dans Larvel sur quelque chose comme 0775. Ce serait bien s'il héritait simplement du parent.
Note latérale
Pour moi, cela causait également un problème avec Cache::remember() entre le processus superviseur et le processus PHP de telle sorte que j'obtenais des erreurs put_file_contents Car les fichiers mis en cache ne pouvaient pas 'pas écrit par les différents utilisateurs.
Réponse originale
J'avais le même problème et dans mon cas, les fichiers n'étaient pas supprimés car ils étaient protégés en écriture. Lorsque je suis allé les supprimer manuellement à l'aide de rm -r ./storage/framework/cache, J'ai reçu l'avertissement rm: descend into write-protected directory 'cache/c5'?. Je n'allais pas taper oui pour chaque fichier dans le cache, j'ai donc exécuté la même commande que Sudo et cela a fonctionné sans accroc Sudo rm -r ./storage/framework/cache.
Cela répond à votre question sur la raison pour laquelle ils ne sont pas supprimés par Artisan cache:clear Et exécuter rm est une solution assez simple; même si cela ne résout pas le problème de l'écriture des fichiers protégés en écriture.
Après avoir supprimé le cache Laravel crée à nouveau le cache comme protégé en écriture. Cela signifie qu'il s'agit probablement d'un bogue et nécessite que quelqu'un soumette un rapport de bogue au Laravel Étant donné que la solution de contournement est triviale, je laisse cette tâche à quelqu'un d'autre.
Tu peux essayer:
php artisan config:cache
Cela résout la plupart de mes problèmes.