Comportement de Vagrant / VirtualBox / Apache2 Strange Cache

J’utilise Vagrant pour faire fonctionner un VirtualBox avec Apache2 sous Ubuntu.

Le serveur Web, entre autres, sert des fichiers statiques de mon répertoire / vagrant.

Cela fonctionne bien la plupart du temps. Mais lorsque je change une image sur mon dossier partagé et que je recharge le site Web, la version précédente de l’image est diffusée, mais elle est tronquée.

Cela fonctionne si je supprime d’abord l’ancienne image de mon dossier partagé, rafraîchit le site Web pour que l’image ne soit PAS affichée, puis enregistre le nouveau fichier et recharge à nouveau le site Web.

Est-ce que quelqu’un connaissait ce problème? Je n’ai rien de spécial installé, juste Apache 2 avec mod_rewrite et PHP avec Mongo, APC Plugin, MongoDB ainsi que nodeJS avec un tas de scripts.

Trouvé la réponse ici :

JC,

Ce que vous voyez est probablement parce que le serveur servant les fichiers statiques utilise le syscall “sendfile ()”, qui est cassé avec le système de fichiers VirtualBox. Vous devez désactiver l’utilisation de sendfile () sur votre serveur. Pour Apache:

EnableSendfile off

Et pour nginx: sendfile off;

Meilleur, Mitchell

Cela m’a rendu fou! Merci d’avoir posté ce Philipp. Pour ceux d’entre vous qui ne savent pas comment changer le fichier de configuration, voici ce que j’ai fait:

Pour trouver le fichier: $ sudo find -name "nginx.conf"

Le mien était ici: ./etc/nginx/nginx.conf

Donc j’ai couru ceci pour le modifier: $ sudo nano ./etc/nginx/nginx.conf

Changer la ligne qui contient sendfile on; sendfile off;

N’oubliez pas de exit et de vagrant reload !

C’est un ancien bogue dans VirtualBox (voir: # 819 , # 9069 , # 12597 , # 14920 ) où vboxvfs semble avoir des problèmes avec l’access mmappé aux fichiers qui sont synchronisés.

Cela peut se produire lorsque vous modifiez le fichier en dehors de la machine virtuelle et que vous vous attendez à voir la même modification dans la machine virtuelle.

Pour contourner ce problème, vous devez désactiver le support sendfile du kernel pour dissortingbuer les fichiers au client en désactivant l’ option EnableSendfile , dans le fichier httpd.conf ou dans le fichier vhosts, par exemple

  EnableSendfile Off  

Ceci est particulièrement problématique pour les fichiers montés NFS ou SMB. Après le changement, rechargez l’Apache.

Similaire pour Nginx (dans nginx.conf ), par exemple

 sendfile off; 

Une autre solution consiste à ne pas modifier les fichiers sur l’hôte ou à rééditer le même fichier, mais dans la machine virtuelle.


Une autre solution de contournement consiste à supprimer le cache de Linux, par exemple

 echo 1 > /proc/sys/vm/drop_caches 

Ou pour effacer les caches chaque seconde (selon ce post ), essayez:

 watch -n 1 $(sync; echo 1 > /proc/sys/vm/drop_caches) 

Nota: Le numéro 1 signifie «libérer le pagecache», 2 pour les dentiers et les inodes, 3 pour les pagecache, les denteries et les inodes.


Le problème ci-dessus peut être répliqué par le programme mmap-test suivant, voir: mmap-problem.c .

J’ai un problème similaire avec l’environnement VirtualBox / Docker / Nginx.

La décision de supprimer Linux pagecache echo 1 > /proc/sys/vm/drop_caches fonctionne bien, mais semble gênante.

Aussi la directive sendfile off; dans le nginx.conf n’a pas résolu le problème et j’ai essayé de l’utiliser avec expires off; directive ensemble et il a réussi.

Donc, ma décision ressemble à

 sendfile off; expires off; 

Pour quiconque utilise Laravel 5, Debugbar et browserSync de Barryvdh via gulp.watch, vous pouvez obtenir cette erreur. J’ai eu exactement la même erreur en raison de la façon dont le navigateur Sync faisait le relais de ma demande. Si j’ai consulté mon serveur de dev via: http://127.0.0.1:3000/laravel/page, l’erreur http://127.0.0.1/laravel/page a disparu.

Je l’ai signalé avec nos amis de browserSync, ils font un travail formidable. Donc, c’est plus une raison qu’une solution, mais plutôt que de passer des heures à essayer de le réparer, testez pour voir si c’est votre problème avant de perdre plus de temps.

Ce problème est également similaire aux erreurs trouvées dans cet article

Cela était également responsable du comportement étrange concernant les fichiers CSS dans une configuration CentOS / VirtualBox.

Vous pourriez changer le contenu d’un fichier CSS dans le dossier / vagrant, et le navigateur afficherait un statut de 200 (au lieu d’un 304), ce qui signifie qu’il savait que le fichier était nouveau. Mais le contenu n’aurait pas changé.