Tous les scripts de la CLI PHP vagrants sont bloqués en attente d’une résolution de l’hôte sur Mac OS X

Je me suis fait avoir lors de l’exécution de commandes PHP sur ma boîte vaginale Homestead sous Ubuntu. Il y a un décalage important avant que la console ne commence l’exécution php cli.

Ran strace -vyT -S time php artisan help de la boîte vagrant. Tout rest bloqué pendant plusieurs minutes le premier au dernier appel à recvfrom(3 , mais je ne sais pas pourquoi:

 open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3  fstat(3, {st_dev=makedev(0, 16), st_ino=7632, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=171, st_atime=2015/10/17-04:53:56, st_mtime=2015/10/17-04:53:54, st_ctime=2015/10/17-04:53:54}) = 0  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed9385c000  read(3, "# Dynamic resolv.conf(5) file fo"..., 4096) = 171  read(3, "", 4096) = 0  close(3) = 0  munmap(0x7fed9385c000, 4096) = 0  uname({sysname="Linux", nodename="homestead", release="3.13.0-65-generic", version="#106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015", machine="x86_64", domainname="(none)"}) = 0  stat("/etc/resolv.conf", {st_dev=makedev(0, 16), st_ino=7632, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=171, st_atime=2015/10/17-04:53:56, st_mtime=2015/10/17-04:53:54, st_ctime=2015/10/17-04:53:54}) = 0  open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3  fstat(3, {st_dev=makedev(8, 1), st_ino=1161, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=251, st_atime=2015/10/16-18:57:29, st_mtime=2014/10/03-01:16:42, st_ctime=2014/10/03-01:16:42}) = 0  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed9385c000  read(3, "127.0.0.1 localhost\n\n# The follo"..., 4096) = 251  read(3, "", 4096) = 0  close(3) = 0  munmap(0x7fed9385c000, 4096) = 0  socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3  fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0  connect(3, {sa_family=AF_INET, sin_port=htons(9000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)  select(4, [3], [3], [3], {0, 200000}) = 1 (out [3], left {0, 199997})  getpeername(3, {sa_family=AF_INET, sin_port=htons(9000), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0  fcntl(3, F_SETFL, O_RDONLY) = 0  setsockopt(3, SOL_TCP, TCP_NODELAY, "\1\0\0\0\0\0\0\0", 8) = 0  write(3, "478\0<?xml version=\"1.0\" encoding"..., 483) = 483  brk(0x2f93000) = 0x2f93000  recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = -1 ECONNRESET (Connection reset by peer)  

Voici le contenu de /etc/hosts :

 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts 127.0.1.1 homestead homestead 

Le contenu de /etc/resolve.conf :

 # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.0.2.3 

Le problème concerne désormais TOUS les vagrants non apparentés, pas seulement la boîte Homestead. Presque toutes les commandes PHP sur chaque boîte sont bloquées de 5 à 15 minutes pour chaque exécution de la CLI. Si une chaîne de commandes doit être appelée, cela peut prendre une heure pour terminer un processus qui devrait durer 30 secondes.

Cela a commencé après que le Mac sur lequel ces boîtes ont été exécutées a été mis à niveau vers El Capitan.

Selon la boîte vagrante, parfois cette ligne de marche:

 connect(3, {sa_family=AF_INET, sin_port=htons(9000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 

Est remplacé par:

 connect(3, {sa_family=AF_INET, sin_port=htons(9000), sin_addr=inet_addr("192.168.56.1")}, 16) = 0 

L’IP 192.168.56.1 semble être le routeur par défaut pour VirtualBox.

S’il vous plaît noter que toutes les boîtes vagrant sont soit la configuration standard ou ceux qui fonctionnent sans problème sur les systèmes Mac / Windows de mon autre membre de l’équipe.

Vagrant 1.7.4 et VirtualBox 4.3.30.

En réponse à la requête route -n :

 Kernel IP routing table Destination Gateway Genmask Flags Mesortingc Ref Use Iface 0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 

Résultats pour sudo netstat -tulnp | grep 9000 sudo netstat -tulnp | grep 9000 :

 tcp6 0 0 :::9000 :::* LISTEN 1317/hhvm 

Pourquoi hhvm apparaît, je ne sais pas, car la boîte est censée utiliser l’interpréteur PHP standard.

tl; dr : je blâme le client xdebug. Essayez de désactiver xdebug sur Ubuntu.

Ma raison :

Je ne vois aucun problème avec la résolution de l’hôte dans le journal strace.

Il vérifie d’abord /etc/resolv.conf , puis /etc/hosts et se connecte à 127.0.0.1:9000 connect(3, {sa_family=AF_INET, sin_port=htons(9000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000094>

Le port 9000 est la valeur par défaut pour xdebug, à moins d’être redéfinie dans /etc/php5/mods-available/xdebug.ini ou similaire.

write(3, "478\0 ressemble à un message envoyé depuis l’extension xdebug au client.

Il attend 2 minutes recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS recvfrom(3, 0x7ffc489b16d0, 128, 0, 0, 0) = ? ERESTARTSYS , puis abandonne et exécute votre script php.

Le temps d’attente a été réduit à 200 ms depuis la v2.2.4: https://github.com/xdebug/xdebug/pull/90

En supposant que la désactivation de xdebug résout le problème, il y a peu d’options:

  • mettre à jour xdebug
  • configurer xdebug pour démarrer à la demande uniquement avec xdebug.remote_autostart=off
  • continuez à activer / désactiver xdebug
  • garder le client xdebug toujours allumé et s’assurer que les ports sont correctement mappés et ne sont pas bloqués

Le problème semble lié à la résolution du nom d’hôte. si vous essayez d’utiliser votre ip au lieu de ip localhost 127.0.0.1 . préférable d’utiliser dans /etc/hosts comme:

 yourip hostname.example.com hostname 

par exemple

 10.0.2.20 test.example.com test 

et supprimer localhost lié à /etc/hosts ou garder enfin. Le système essaiera de prendre la première entrée et si vous n’utilisez pas ipv6 vous pouvez également supprimer l’entrée associée à ipv6.

EDIT: votre fichier /etc/resolv.conf doit avoir une ligne /etc/resolv.conf

 nameserver 127.0.0.1 

ajoutez également le réseau par défaut vagrant parce que votre sortie le montre en train d’essayer de se connecter mais si vous ne voulez pas l’utiliser, vous pouvez sauter. vous utilisez 127.0.0.1 donc au moins il devrait être là.vous pouvez prendre l’aide pour changer d’ ici et ici .

Eh bien, c’est comme un problème de DNS. Je suppose que votre ordinateur ne peut pas résoudre le DNS via le nom d’hôte donné ou que le serveur DNS est lent. Mon conseil serait d’installer un serveur DNS en cache localement, et de l’utiliser, et d’append au fichier / etc / hosts n’importe quoi dans un réseau privé, qui ne sera pas servi par DNS. Utilisez NetworkManager ou n’importe quel service réseau auquel vous devez append 127.0.0.1 en tant que serveur DNS viable (et préféré), et tout devrait bien se passer. Si vous utilisez ubuntu, cela devrait être aussi simple que sudo apt-get install bind9.

Si vous voulez diagnostiquer le problème, installez d’abord dnsutils, pour obtenir dig et nslookup, et essayez de demander quelque chose, comme http://www.google.co.uk, pour voir combien de temps cela prend et quel serveur fait autorité. Ensuite, essayez de creuser, pour être plus précis, interrogez directement le serveur, interrogez directement la SOA, et voyez si vous pouvez déterminer le lien le plus faible.

Il s’agit probablement d’un routeur qui s’annonce lui-même en tant que service DNS via DHCP, mais ne fonctionne pas correctement lorsqu’il est pressé.