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
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:
xdebug.remote_autostart=off
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é.