Comportement étrange du cache de Vagrant/VirtualBox/Apache2

Question

J'utilise Vagrant pour faire fonctionner une VirtualBox sous Ubuntu avec Apache2.

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

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

Cela fonctionne si je supprime d'abord l'ancienne image de mon dossier partagé, si je rafraîchis le site Web pour que l'image ne s'affiche PAS, puis si j'enregistre le nouveau fichier et recharge le site Web.

Quelqu'un connaît-il 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.

Answer 1

J'ai trouvé la réponse ici :

JC,

Ce que vous voyez est probablement parce que le serveur qui sert les fichiers statiques utilise l'appel système "sendfile()", qui ne fonctionne pas avec le fichier de VirtualBox. de fichiers de VirtualBox. Vous devez désactiver l'utilisation de sendfile() dans votre serveur. Pour Apache :

EnableSendfile off

Et pour nginx : sendfile off ;

Le meilleur, Mitchell

Answer 2

Cela m'a rendu fou ! Merci d'avoir posté ce Philipp. Pour ceux qui n'ont aucune idée de la façon de modifier 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

Alors j'ai lancé ceci pour le modifier : $ sudo nano ./etc/nginx/nginx.conf

Changez la ligne qui contient sendfile on; a sendfile off;

N'oubliez pas de exit y vagrant reload !

Answer 3

Il s'agit d'un ancien bug de VirtualBox (voir : #819 , #9069 , #12597 , #14920 ) où vboxvfs semble avoir quelques problèmes avec l'accès mmappé aux fichiers qui sont synchronisés.

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

Pour contourner ce problème, vous devez désactiver la prise en charge de sendfile par le noyau pour livrer les fichiers au client en désactivant la fonction EnableSendfile option soit dans httpd.conf ou dans le fichier vhosts, par ex.

<Directory "/path-to-nfs-files">
  EnableSendfile Off
</Directory>

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

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

sendfile off;

---

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

---

Une autre solution consiste à supprimer le cache de pages de Linux, par ex.

echo 1 > /proc/sys/vm/drop_caches

Ou pour vider les caches toutes les secondes (comme dans le cas de ce poste ), essayez :

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

Note : Le numéro 1 signifie libérer le cache de la page, le numéro 2 signifie libérer les dentries et les inodes, le numéro 3 signifie libérer le cache de la page, les dentries et les inodes.

---

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

Answer 4

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

La décision d'abandonner le pagecache de Linux echo 1 > /proc/sys/vm/drop_caches fonctionne bien mais a l'air maladroit.

De même, 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; ensemble et c'est réussi.

Donc, ma décision ressemble à

sendfile off;
expires off;

Answer 5

Pour tous ceux qui utilisent Laravel 5, la Debugbar de Barryvdh et browserSync via gulp.watch, vous pouvez obtenir cette erreur. J'ai eu exactement la même erreur à cause de la façon dont browserSync transmettait ma requête. Si je visualisais mon serveur de développement via : http://127.0.0.1:3000/laravel/page J'ai obtenu l'erreur http://127.0.0.1/laravel/page erreur disparue.

Je l'ai signalé à nos amis de browserSync, ils font un travail formidable. C'est donc 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.

Cette question est également similaire à les erreurs trouvées dans cet article