Machine: docker-machine env xxx se bloque pour toujours

J'ai un problème similaire avec Windows 7 OS. voici un aperçu du fichier journal.

Je remarque que "docker-machine env machinename" se bloque aussi beaucoup, surtout quand il se trouve dans mon ~/.profile, ce qui fait que les nouveaux terminaux se bloquent et ne démarrent pas 50% du temps environ. Actuellement, il suffit de ctrl + c'ing le nouvel onglet shell, et d'en générer un autre 2 secondes plus tard a tendance à faire le travail.

Difficile à reproduire dans un terminal nouveau/actif, a tendance à être beaucoup plus souvent lors de la création d'un nouveau.

OSX 10.10.4, Docker Machine 0.3.0. Ces problèmes n'étaient pas présents dans la version 0.2.x.

J'ai le même problème avec un état de sortie étrange 255

docker-machine -D env docker
shell: bash
executing: /Applications/VMware Fusion.app/Contents/Library/vmrun list
MAC address in VMX: 00:0c:29:b6:95:bb
IP found in DHCP lease table: 172.16.1.131
invalid certs detected; regenerating for 172.16.1.131:2376
command=configureAuth machine=docker
executing: /Applications/VMware Fusion.app/Contents/Library/vmrun list
MAC address in VMX: 00:0c:29:b6:95:bb
IP found in DHCP lease table: 172.16.1.131
Using SSH client type: external
About to run SSH command:
cat /etc/os-release
&{/usr/bin/ssh [/usr/bin/ssh -o PasswordAuthentication=no -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -i /Users/orangeudav/.docker/machine/machines/docker/id_rsa -p 22 [email protected] cat /etc/os-release] []  <nil> <nil> <nil> [] <nil> <nil> <nil> <nil> false [] [] [] [] <nil>}
<HAAAAAANGIIING HERE>
SSH cmd err, output: exit status 255:
Error getting SSH command: exit status 255
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://172.16.1.131:2376"
export DOCKER_CERT_PATH="/Users/orangeudav/.docker/machine/machines/docker"
export DOCKER_MACHINE_NAME="docker"
# Run this command to configure your shell:
# eval "$(docker-machine env docker)"

Je suis capable de reproduire ce problème sur MacOSX pour le pilote virtualbox. Le problème se produit généralement lorsque la route vers le réseau privé est manquante (celle utilisée par docker cli).
Dans mon cas, l'une des raisons pour lesquelles je soupçonne que cette route est manquante est que j'utilise un VPN qui a tendance à gâcher les routes du réseau privé. Une solution à ce problème consiste à exécuter quelque chose :

sudo route add -net 192.168.99.0/24 -interface vboxnet6

Où 192.168.99.0/24 est la plage réseau utilisée par boot2docker et vboxnet6 l'interface affectée au réseau privé boot2docker.

J'ai essayé la solution de @chantra mais je n'ai pas réussi, docker-machine se bloque toujours dans un nouveau shell avec n'importe quelle sous-commande. Interrompre avec ^C et réessayer fonctionne, cependant.

Salut à tous, à tous ceux qui rencontrent ce problème, l'un des problèmes possibles en jeu est que le démon Docker ne fonctionne pas.

Pouvez-vous s'il vous plaît essayer/coller la sortie des commandes suivantes (c'est pour les machines virtuelles exécutant boot2docker):

$ docker-machine -D ssh machinename sudo /etc/init.d/docker restart
...
$ docker-machine -D env machinename
...

Merci!

@nathanleclaire lorsque j'essaie d'exécuter cette commande, elle se bloque ici :

$ docker-machine -D ssh dev sudo /etc/init.d/docker restart
executing: /usr/local/bin/VBoxManage showvminfo dev --machinereadable
STDOUT: name="dev"
groups="/"
ostype="Linux 2.6 / 3.x (64-bit)"
UUID="19ac89e0-98cf-49e8-b306-ca58878604a3"
CfgFile="/Users/inkel/.docker/machine/machines/dev/dev/dev.vbox"
SnapFldr="/Users/inkel/.docker/machine/machines/dev/dev/Snapshots"
LogFldr="/Users/inkel/.docker/machine/machines/dev/dev/Logs"
hardwareuuid="19ac89e0-98cf-49e8-b306-ca58878604a3"
memory=2048
pagefusion="off"
vram=8
cpuexecutioncap=100
hpet="on"
chipset="piix3"
firmware="BIOS"
cpus=4
pae="on"
longmode="on"
synthcpu="off"
bootmenu="disabled"
boot1="dvd"
boot2="dvd"
boot3="disk"
boot4="none"
acpi="on"
ioapic="on"
biossystemtimeoffset=0
rtcuseutc="on"
hwvirtex="on"
nestedpaging="on"
largepages="on"
vtxvpid="on"
vtxux="on"
VMState="running"
VMStateChangeTime="2015-07-15T21:20:06.395000000"
monitorcount=1
accelerate3d="off"
accelerate2dvideo="off"
teleporterenabled="off"
teleporterport=0
teleporteraddress=""
teleporterpassword=""
tracing-enabled="off"
tracing-allow-vm-access="off"
tracing-config=""
autostart-enabled="off"
autostart-delay=0
defaultfrontend=""
storagecontrollername0="SATA"
storagecontrollertype0="IntelAhci"
storagecontrollerinstance0="0"
storagecontrollermaxportcount0="30"
storagecontrollerportcount0="30"
storagecontrollerbootable0="on"
"SATA-0-0"="/Users/inkel/.docker/machine/machines/dev/boot2docker.iso"
"SATA-ImageUUID-0-0"="c5d1d610-61ba-4416-8721-f65383bd9595"
"SATA-tempeject"="off"
"SATA-IsEjected"="off"
"SATA-1-0"="/Users/inkel/.docker/machine/machines/dev/disk.vmdk"
"SATA-ImageUUID-1-0"="9719a1db-dfaf-441e-8d8f-47ee0b18293b"
"SATA-2-0"="none"
"SATA-3-0"="none"
"SATA-4-0"="none"
"SATA-5-0"="none"
"SATA-6-0"="none"
"SATA-7-0"="none"
"SATA-8-0"="none"
"SATA-9-0"="none"
"SATA-10-0"="none"
"SATA-11-0"="none"
"SATA-12-0"="none"
"SATA-13-0"="none"
"SATA-14-0"="none"
"SATA-15-0"="none"
"SATA-16-0"="none"
"SATA-17-0"="none"
"SATA-18-0"="none"
"SATA-19-0"="none"
"SATA-20-0"="none"
"SATA-21-0"="none"
"SATA-22-0"="none"
"SATA-23-0"="none"
"SATA-24-0"="none"
"SATA-25-0"="none"
"SATA-26-0"="none"
"SATA-27-0"="none"
"SATA-28-0"="none"
"SATA-29-0"="none"
natnet1="nat"
macaddress1="08002743999C"
cableconnected1="on"
nic1="nat"
nictype1="virtio"
nicspeed1="0"
mtu="0"
sockSnd="64"
sockRcv="64"
tcpWndSnd="64"
tcpWndRcv="64"
Forwarding(0)="ssh,tcp,127.0.0.1,54973,,22"
hostonlyadapter2="vboxnet5"
macaddress2="080027A3AA51"
cableconnected2="on"
nic2="hostonly"
nictype2="82540EM"
nicspeed2="0"
nic3="none"
nic4="none"
nic5="none"
nic6="none"
nic7="none"
nic8="none"
hidpointing="ps2mouse"
hidkeyboard="ps2kbd"
uart1="off"
uart2="off"
lpt1="off"
lpt2="off"
audio="none"
clipboard="disabled"
draganddrop="disabled"
SessionType="headless"
VideoMode="720,400,0"<strong i="7">@0</strong>,0
vrde="off"
usb="off"
ehci="off"
SharedFolderNameMachineMapping1="Users"
SharedFolderPathMachineMapping1="/Users"
VRDEActiveConnection="off"
VRDEClients=0
vcpenabled="off"
vcpscreens=0
vcpfile="/Users/inkel/.docker/machine/machines/dev/dev/dev.webm"
vcpwidth=1024
vcpheight=768
vcprate=512
vcpfps=25
GuestMemoryBalloon=0
GuestOSType="Linux26_64"
GuestAdditionsRunLevel=1
GuestAdditionsVersion="4.3.20 r96996"
GuestAdditionsFacility_VirtualBox Base Driver=50,1436995222662
GuestAdditionsFacility_Seamless Mode=0,1436995222662
GuestAdditionsFacility_Graphics Mode=0,1436995222662

STDERR:
Using SSH client type: external
About to run SSH command:
sudo /etc/init.d/docker restart
&{/usr/bin/ssh [/usr/bin/ssh -o PasswordAuthentication=no -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -i /Users/inkel/.docker/machine/machines/dev/id_rsa -p 54973 docker<strong i="8">@localhost</strong> sudo /etc/init.d/docker restart] []  <nil> <nil> <nil> [] <nil> <nil> <nil> ?reflect.Value? false [] [] [] [] <nil>}

Une fois si fini (si c'est le cas), je collerai la suite.

@inkel Hm, il devrait s'exécuter à peu près tout de suite s'il doit réussir, donc si cela prend plus de quelques secondes, quelque chose ne va pas.

Il vient de se terminer avec :

SSH cmd err, output: <nil>:

Cela a pris définitivement plus de quelques secondes. Je cours à nouveau avec time pour voir combien.

$ docker-machine -D ssh dev sudo /etc/init.d/docker restart
…same long output…
real    5m1.197s
user    0m0.045s
sys 0m0.035s

Si vous exécutez :

$ /usr/bin/ssh -vvv -o PasswordAuthentication=no -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -i /Users/inkel/.docker/machine/machines/dev/id_rsa -p 54973 docker<strong i="6">@localhost</strong> sudo /etc/init.d/docker restart

de la CLI seule, qu'est-ce que vous obtenez ?

inkel<strong i="5">@miralejos</strong> ~
$ /usr/bin/ssh -vvv -o PasswordAuthentication=no -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -i /Users/inkel/.docker/machine/machines/dev/id_rsa -p 54973 docker<strong i="6">@localhost</strong> sudo /etc/init.d/docker restart 2>&1 | pbcopy
debug1: multiplexing control connection
debug3: fd 7 is O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [mux-control]
debug3: channel_post_mux_listener: new mux channel 1 fd 7
debug3: mux_master_read_cb: channel 1: hello sent
debug2: set_control_persist_exit_time: cancel scheduled exit
debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4
debug2: process_mux_master_hello: channel 1 slave version 4
debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4
debug2: process_mux_alive_check: channel 1: alive check
debug3: mux_master_read_cb: channel 1 packet type 0x10000002 len 92
debug2: process_mux_new_session: channel 1: request tty 0, X 1, agent 0, subsys 0, term "xterm", cmd "sudo /etc/init.d/docker restart", env 1
debug3: process_mux_new_session: got fds stdin 8, stdout 9, stderr 10
debug2: fd 9 setting O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 2: new [client-session]
debug2: process_mux_new_session: channel_new: 2 linked to control channel 1
debug2: channel 2: send open
debug2: callback start
debug2: client_session2_setup: id 2
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 2: request env confirm 0
debug1: Sending command: sudo /etc/init.d/docker restart
debug2: channel 2: request exec confirm 1
debug3: mux_session_confirm: sending success reply
debug2: callback done
debug2: channel 2: open confirm rwindow 0 rmax 32768
debug2: channel 2: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 2
debug2: exec request accepted on channel 2
debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
debug3: mux_exit_message: channel 2: exit message, evitval 0
debug1: client_input_channel_req: channel 2 rtype [email protected] reply 0
debug2: channel 2: rcvd eow
debug2: channel 2: close_read
debug2: channel 2: input open -> closed
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain -> closed
debug2: channel 2: rcvd close
debug3: channel 2: will not send data after close
debug2: channel 2: send close
debug2: channel 2: is dead
debug2: channel 2: gc: notify user
debug3: mux_master_session_cleanup_cb: entering for channel 2
debug2: channel 1: rcvd close
debug2: channel 1: output open -> drain
debug2: channel 1: close_read
debug2: channel 1: input open -> closed
debug2: channel 2: gc: user detached
debug2: channel 2: is dead
debug2: channel 2: garbage collecting
debug1: channel 2: free: client-session, nchannels 3
debug3: channel 2: status: The following connections are open:
  #2 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug2: channel 1: is dead (local)
debug2: channel 1: gc: notify user
debug3: mux_master_control_cleanup_cb: entering for channel 1
debug2: channel 1: gc: user detached
debug2: channel 1: is dead (local)
debug2: channel 1: garbage collecting
debug1: channel 1: free: mux-control, nchannels 2
debug3: channel 1: status: The following connections are open:

debug2: set_control_persist_exit_time: schedule exit in 300 seconds
inkel<strong i="7">@miralejos</strong> ~
$

Je pense que j'ai fait une erreur avec mon commentaire précédent, c'est la bonne sortie:

$ /usr/bin/ssh -vvv -o PasswordAuthentication=no -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -i /Users/inkel/.docker/machine/machines/dev/id_rsa -p 54973 docker<strong i="6">@localhost</strong> sudo /etc/init.d/docker restart 2>&1
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/inkel/.ssh/config
debug1: /Users/inkel/.ssh/config line 3: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/inkel/.ssh/master-docker<strong i="7">@localhost</strong>:54973" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 54973.
debug2: fd 5 setting O_NONBLOCK
debug1: connect to address ::1 port 54973: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 54973.
debug2: fd 5 setting O_NONBLOCK
debug1: fd 5 clearing O_NONBLOCK
debug1: Connection established.
debug3: timeout: 10000 ms remain after connect
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/inkel/.docker/machine/machines/dev/id_rsa" as a RSA1 public key
debug1: identity file /Users/inkel/.docker/machine/machines/dev/id_rsa type 1
debug1: identity file /Users/inkel/.docker/machine/machines/dev/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0
debug1: match: OpenSSH_6.0 pat OpenSSH*
debug2: fd 5 setting O_NONBLOCK
debug3: put_host_port: [localhost]:54973
debug3: load_hostkeys: loading entries for host "[localhost]:54973" from file "/dev/null"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 124/256
debug2: bits set: 526/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 4c:94:a7:2d:b9:b3:b5:a2:1d:37:89:c8:84:d9:ed:bf
debug3: put_host_port: [127.0.0.1]:54973
debug3: put_host_port: [localhost]:54973
debug3: load_hostkeys: loading entries for host "[localhost]:54973" from file "/dev/null"
debug3: load_hostkeys: loaded 0 keys
debug1: checking without port identifier
debug3: load_hostkeys: loading entries for host "localhost" from file "/dev/null"
debug3: load_hostkeys: loaded 0 keys
Warning: Permanently added '[localhost]:54973' (RSA) to the list of known hosts.
debug2: bits set: 519/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/inkel/.docker/machine/machines/dev/id_rsa (0x7feeca600150), explicit
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/inkel/.docker/machine/machines/dev/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 8b:f1:19:49:34:18:61:8c:ba:cd:a5:65:99:aa:ce:ea
debug3: sign_and_send_pubkey: RSA 8b:f1:19:49:34:18:61:8c:ba:cd:a5:65:99:aa:ce:ea
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to localhost ([127.0.0.1]:54973).
debug1: setting up multiplex master socket
debug3: muxserver_listen: temporary control path /Users/inkel/.ssh/master-docker<strong i="8">@localhost</strong>:54973.bGmwLqk9AzPAnw76
debug2: fd 6 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [/Users/inkel/.ssh/master-docker<strong i="9">@localhost</strong>:54973]
debug3: muxserver_listen: mux listener channel 0 fd 6
debug1: control_persist_detach: backgrounding master process
debug2: control_persist_detach: background process is 15146
debug2: fd 6 setting O_NONBLOCK
debug1: forking to background
debug1: Entering interactive session.
debug2: set_control_persist_exit_time: schedule exit in 300 seconds
debug1: multiplexing control connection
debug3: fd 7 is O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [mux-control]
debug3: channel_post_mux_listener: new mux channel 1 fd 7
debug3: mux_master_read_cb: channel 1: hello sent
debug2: set_control_persist_exit_time: cancel scheduled exit
debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4
debug2: process_mux_master_hello: channel 1 slave version 4
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4
debug2: process_mux_alive_check: channel 1: alive check
debug3: mux_client_request_alive: done pid = 15147
debug3: mux_client_request_session: session request sent
debug3: mux_master_read_cb: channel 1 packet type 0x10000002 len 92
debug2: process_mux_new_session: channel 1: request tty 0, X 1, agent 0, subsys 0, term "xterm", cmd "sudo /etc/init.d/docker restart", env 1
debug3: process_mux_new_session: got fds stdin 8, stdout 9, stderr 10
debug1: channel 2: new [client-session]
debug2: process_mux_new_session: channel_new: 2 linked to control channel 1
debug2: channel 2: send open
debug2: callback start
debug2: client_session2_setup: id 2
debug2: fd 5 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x08
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 2: request env confirm 0
debug1: Sending command: sudo /etc/init.d/docker restart
debug2: channel 2: request exec confirm 1
debug3: mux_session_confirm: sending success reply
debug2: callback done
debug2: channel 2: open confirm rwindow 0 rmax 32768
debug1: mux_client_request_session: master session id: 2
debug2: channel 2: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 2
debug2: exec request accepted on channel 2
debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
debug3: mux_exit_message: channel 2: exit message, evitval 0
debug1: client_input_channel_req: channel 2 rtype [email protected] reply 0
debug2: channel 2: rcvd eow
debug2: channel 2: close_read
debug2: channel 2: input open -> closed
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain -> closed
debug2: channel 2: rcvd close
debug3: channel 2: will not send data after close
debug2: channel 2: send close
debug2: channel 2: is dead
debug2: channel 2: gc: notify user
debug3: mux_master_session_cleanup_cb: entering for channel 2
debug2: channel 1: rcvd close
debug2: channel 1: output open -> drain
debug2: channel 1: close_read
debug2: channel 1: input open -> closed
debug2: channel 2: gc: user detached
debug2: channel 2: is dead
debug2: channel 2: garbage collecting
debug1: channel 2: free: client-session, nchannels 3
debug3: channel 2: status: The following connections are open:
  #2 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug2: channel 1: is dead (local)
debug2: channel 1: gc: notify user
debug3: mux_master_control_cleanup_cb: entering for channel 1
debug2: channel 1: gc: user detached
debug2: channel 1: is dead (local)
debug2: channel 1: garbage collecting
debug1: channel 1: free: mux-control, nchannels 2
debug3: channel 1: status: The following connections are open:

debug2: set_control_persist_exit_time: schedule exit in 300 seconds
debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Received exit status from master 0

Mmm... après quelques minutes, ce qui suit est apparu sur mon écran :

debug1: ControlPersist timeout expired
debug1: channel 0: free: /Users/inkel/.ssh/master-docker<strong i="6">@localhost</strong>:54973, nchannels 1
debug3: channel 0: status: The following connections are open:

debug3: fd 0 is not O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 3104, received 2480 bytes, in 301.1 seconds
Bytes per second: sent 10.3, received 8.2
debug1: Exit status -1

@inkel Impair. Avez-vous un VPN ou une configuration inhabituelle en ce qui concerne votre réseau à laquelle vous pouvez penser ?

Non, pas que je puisse penser. Il y a quelques jours, j'utilisais encore 0.1.0 et fonctionnait parfaitement, puis mis à jour vers 0.3.0 et il a commencé à fonctionner aussi bien qu'actuellement. J'ai un autre collègue, @fsaravia , qui souffre du même problème.

@nathanleclaire après avoir parlé avec mon collègue, j'ai découvert que j'utilisais la version suivante, car celle de l'homebrew me donnait cette erreur :

$ docker-machine -v
docker-machine version 0.3.0 (0a251fe)

Il utilise la dernière version, j'ai donc supprimé cette version, brew install docker-machine et semble maintenant fonctionner :smile_cat: désolé pour le problème.

@inkel Nice, content que cela fonctionne.

Je viens de réessayer avec la version la plus récente de docker-machine sans succès. Je suis sous windows 7 avec git shell. Toutes les étapes et les sorties respectives sont ici .

Le fichier out.log contient les principales étapes. Ensuite, il y a un docker-machine-create.log et un docker-machine-env.log

Après avoir copié manuellement les fichiers cert de /var/lib/boot2docker/tls/ vers /c/Users/Pedro/.docker/machine/machines/test/

J'ai fait un autre essai et le journal résultant est docker-machine-env-2.log
Même avec les variables d'environnement exportées à la fin, je ne parviens toujours pas à me connecter.
docker ps terminé avec une erreur de délai d'attente

La machine virtuelle a démarré et le service docker était en train de se ruiner.
Je peux ssh sur la machine et le service docker écoute sur le bon port (2376)

docker<strong i="15">@test</strong>:~$ netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 10.0.2.15:22            10.0.2.2:57901          ESTABLISHED
tcp        0      0 :::2376                 :::*                    LISTEN
tcp        0      0 :::22                   :::*                    LISTEN
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     SEQPACKET  LISTENING      14092 /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING      17142 /var/run/acpid.socket
unix  2      [ ACC ]     STREAM     LISTENING      17656 /var/run/docker.sock
unix  3      [ ]         DGRAM                     14101
unix  3      [ ]         STREAM     CONNECTED      22738
unix  3      [ ]         STREAM     CONNECTED      22737
unix  3      [ ]         DGRAM                     14100

La chose intéressante est que boot2docker fonctionne très bien.
D'autres réflexions ?
Merci.

Ce problème est vraiment difficile à reproduire... Après avoir supprimé tous les vmboxnet_x à l'exception de vmboxnet0 et vmboxnet1, et redémarré l'ordinateur (plutôt que docker-machine), mon problème a disparu.

Après avoir mis mon ordinateur en veille plusieurs fois, puis réessayé, j'ai commencé à avoir le même problème. Quand j'ai eu un moment pour le redémarrer complètement, je vais réessayer et voir ce qui se passe.

J'ai les dernières versions de toutes les applications Docker. J'ai eu le problème pendant des semaines avec Docker Machine sur Linux Ubuntu créant des machines virtuelles VirtualBox. Je viens d'ajouter Docker Swarm et le problème s'est aggravé plusieurs fois (plus fréquent). J'ai passé deux heures à essayer de créer trois machines à essaim. Si je redémarre, cela le résout généralement, mais ce n'est pas raisonnable. En utilisant le --debug de docker-machine, vous pouvez voir où il se bloque, comme l'ont souligné d'autres commentateurs. Je le vois se bloquer à quelques endroits avec Daemon not responding yet: dial tcp 192.168.99.XXX:2376: no route to host , mais le délai d'attente se produit toujours à ce stade :

STDERR: 
Using SSH client type: external
About to run SSH command:
ip addr show dev eth1
&{/usr/bin/ssh [/usr/bin/ssh -o PasswordAuthentication=no -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -i /home/gstafford/.docker/machine/machines/swarm-node-02/id_rsa -p 58710 docker<strong i="7">@localhost</strong> ip addr show dev eth1] []  <nil> <nil> <nil> [] <nil> <nil> <nil> ?reflect.Value? false [] [] [] [] <nil>}
SSH cmd err, output: <nil>: 4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:9d:c5:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.105/24 brd 192.168.99.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe9d:c53d/64 scope link 
       valid_lft forever preferred_lft forever

SSH returned: 4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:9d:c5:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.105/24 brd 192.168.99.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe9d:c53d/64 scope link 
       valid_lft forever preferred_lft forever

END SSH

Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Daemon not responding yet: dial tcp 192.168.99.105:2376: no route to host
Error creating machine: Maximum number of retries (60) exceeded
You will want to check the provider to make sure the machine and associated resources were properly removed.

@garystafford à quoi ressemble la configuration ssh de votre utilisateur ? voir : https://github.com/docker/machine/issues/1591

La solution de @chantra a fonctionné pour moi. en effet, la cause était que mes itinéraires étaient écrasés par le logiciel VPN

Je viens de rencontrer cela aussi, la solution de @chantra a également fonctionné pour moi. Cisco AnyConnect :rage :

Aussi Cisco AnyConnect. Je ne suppose pas que vous puissiez ajouter une vérification qui recommande de réparer la table de routage si elle a été mutilée par un logiciel comme celui-ci? C'est TRÈS frustrant de diagnostiquer; J'ai toujours pu me connecter à la machine docker, qui a démarré avec succès, et j'ai dû regarder de nombreux tickets avant de trouver la discussion dans celui-ci.

Je ne suppose pas que vous puissiez ajouter une vérification qui recommande de réparer la table de routage si elle a été mutilée par un logiciel comme celui-ci?

C'est en fait la solution exacte que j'envisage en ce moment. Dans de nombreux cas, il semble que nous puissions terminer avec succès la création de l'instance et obtenir une adresse IP, il se trouve qu'elle n'est tout simplement pas accessible.

J'ai aussi le problème du docker inaccessible après le sommeil .

Comment feriez-vous la solution de @chantra dans Windows 10 ?

J'ai également rencontré ce problème après plusieurs sommeils.
le redémarrage a résolu le problème..

Cela m'est arrivé aussi lorsque j'ai exécuté docker-machine et que j'ai ensuite accédé à un VPN, la commande se bloque pour toujours.
Cependant, je suis descendu du VPN, la machine a redémarré docker-machine restart <MACHINE-NAME> et elle a recommencé à fonctionner.

Cela m'est arrivé aussi lorsque j'ai exécuté docker-machine et que j'ai ensuite accédé à un VPN, la commande se bloque pour toujours.
Cependant, je suis descendu du VPN, la machine a redémarré le redémarrage de docker-machineet il a recommencé à fonctionner.

Cela m'est arrivé aussi : j'avais une machine docker en cours d'exécution, je suis entré sur VPN, je suis sorti du VPN et docker env <MACHINE-NAME> bloque

Cependant, j'ai fait docker-machine restart <MACHINE-NAME> et cela n'a pas aidé -- docker env <MACHINE-NAME> est toujours suspendu.

J'ai aussi ce problème sur Mac OS 10.10.4 avec le VPN Cisco AnyConnect.

• Nouveau démarrage, docker fonctionne bien
• allez sur le VPN, reculez
• docker-machine env default se bloque

J'ai essayé de redémarrer la machine docker par défaut, le problème persiste.

La solution de @chantra semble fonctionner pour moi. Sur ma machine, l'interface était vboxnet0 (trouvé en utilisant ifconfig à partir du terminal mac) Bien plus facile que de redémarrer chaque fois que je dois aller sur le VPN.

Je ne suis pas sûr d'avoir commenté le VPN que j'utilisais, mais FWIW, j'utilise également Cisco
n'importe quelle connexion....

Le mercredi 23 septembre 2015 à 19h52, Joe McGlynn [email protected]
a écrit:

J'ai aussi ce problème sur Mac OS 10.10.4 avec Cisco AnyConnect
VPN.

• Nouveau démarrage, docker fonctionne bien
• allez sur le VPN, reculez
• docker-machine env default se bloque

J'ai essayé de redémarrer la machine docker par défaut, le problème persiste.

La solution de @chantra https://github.com/chantra semble fonctionner pour moi. Au
ma machine l'interface était vboxnet0 (trouvé en utilisant ifconfig du mac
terminal) Bien plus facile que de redémarrer à chaque fois que j'ai besoin d'aller sur le VPN.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/machine/issues/1500#issuecomment-142788894 .

FWIW J'utilisais également Cisco AnyConnect VPN, sur OS X 10.10.5, je viens d'essayer openconnect à la place et cela semble éviter le problème.

@ronen , Merci pour le conseil sur openconnect, je ne savais pas que cela existait. Au revoir AnyConnect :souriant:

@ChrisRut ouais, je viens d'apprendre sur openconnect en essayant de résoudre ce problème. Au revoir AnyConnect en effet ! J'ai trouvé openconnect un peu lourd à utiliser, alors j'ai créé un wrapper rapide qui vous permet de taper simplement "vpn up" et "vpn down". C'est sur https://gist.github.com/ronen/7d486adbde5d6bfd2472 si vous êtes intéressé

Comme il semble que nous ayons plusieurs problèmes sur des symptômes similaires, j'ai ouvert # 1934 pour ceux qui rencontrent des problèmes sur les hôtes Windows 10 (ou peut-être d'autres versions) après le sommeil. Afin de séparer les préoccupations, je suggère de bien vouloir relier le titre de ce problème aux problèmes de réseau VPN.

J'obtiens ce problème après que ma machine hôte se soit endormie, et j'y reviens plus tard. Je finis par tout supprimer de mon dossier c:usersdan.dockermachine (autre que le cache), puis tout recréer. C'est plus rapide que de redémarrer la machine hôte ! ;)

Oh, et je dois aussi tuer certains processus avant de le faire. J'ai tendance à avoir 3 processus 'VBoxHeadless.exe', 3 'VBoxNetDHCP.exe' et une 'VirtualBox Interface'.

J'ai réveillé mon bloc-notes et supprimé une instance de docker-machine avec le nom "dev".
J'ai exécuté les commandes suivantes pour créer deux nouvelles machines virtuelles :

$ docker-machine create \
    --driver virtualbox \
    --engine-env HTTP_PROXY=http://10.206.246.20:8080 \
    --engine-env HTTPS_PROXY=http://10.206.246.20:8080 \
    --virtualbox-hostonly-cidr "169.254.0.20/16" \
    registry  
$ eval $(docker-machine env registry --shell=bash)
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$ docker run -d -p 5000:5000 --restart=always --name registry registry
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                    NAMES
7001a595cc28        registry            "docker-registry"   27 seconds ago      Up 24 seconds       0.0.0.0:5000->5000/tcp   registry
$ docker-machine ip registry
169.254.0.100
$ docker-machine create \
    --driver virtualbox \
    --engine-env HTTP_PROXY=http://10.206.246.20:8080 \
    --engine-env HTTPS_PROXY=http://10.206.246.20:8080 \
    --engine-insecure-registry "$(docker-machine env registry):5000" \
    --virtualbox-hostonly-cidr "169.254.0.20/16" \
    dev
$ docker-machine ip dev
169.254.0.101
$ eval $(docker-machine env dev --shell=bash)

Le docker-machine env dev --shell=bash bloque pendant quelques minutes et envoie ce qui suit à stderr :

C:\Program Files\ConEmu>docker-machine -D env dev --shell=bash > c:\tmp\docker-machine_env.log
Maximum number of retries (60) exceeded

La sortie du journal stdout peut être trouvée dans ce Gist .

La chose étrange est que la sortie correcte est vidé une fois que le nombre maximum de tentatives est atteint, voir la fin du journal.

Voici la sortie stdout temporisée :

$ time docker-machine env dev --shell=bash
Maximum number of retries (60) exceeded
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://169.254.0.101:2376"
export DOCKER_CERT_PATH="C:\Users\mrumpf\.docker\machine\machines\dev"
export DOCKER_MACHINE_NAME="dev"
# Run this command to configure your shell:
# eval "$(C:\cygwin64\home\mrumpf\bin\docker-machine.exe env dev)"

real    4m8.802s
user    0m0.015s
sys     0m0.078s

Et ça devient de plus en plus étrange...
La même commande pour la première machine virtuelle est exécutée sans aucun problème :

$ time docker-machine env registry --shell=bash
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://169.254.0.100:2376"
export DOCKER_CERT_PATH="C:\Users\mrumpf\.docker\machine\machines\registry"
export DOCKER_MACHINE_NAME="registry"
# Run this command to configure your shell:
# eval "$(C:\cygwin64\home\mrumpf\bin\docker-machine.exe env registry)"

real    0m2.129s
user    0m0.000s
sys     0m0.093s

@mrumpf Si vous ajoutez une barre oblique à la fin des options *PROXY, par exemple --engine-env HTTP_PROXY=http://10.206.246.20:8080/ , réussit-il ou continue-t-il d'échouer ?

Je reçois ceci en ce moment sur Debian 8.2.

Ajoutez Jupiter Junos Pulse à la liste des logiciels VPN qui semblent causer ce problème.

Il me semble probable que _any_ VPN ferait cela, car ils ont tous la même définition fondamentale pour remplacer le routage "ordinaire".

Mise à jour : en utilisant une "connexion fractionnée" (une option que permet mon installation. en me connectant à un serveur VPN différent), je semble éviter cela.

Attends quoi? Je n'utilise aucun type de VPN ou de proxy...

Le VPN n'est qu'une des nombreuses choses qui gâchent la configuration du réseau. Plus généralement, tout changement dans les connexions réseau peut (et cela inclut certaines choses que vous pourriez ne pas considérer comme du "réseau") :

• Activer/désactiver VPN
• Connexion/déconnexion LAN filaire
• Activer/désactiver/changer de zone WiFi (comme transporter un ordinateur portable dans une autre zone du bâtiment)
• Connexion/déconnexion d'un appareil Bluetooth (à cause de Bluetooth PAN )
• même périphérique USB connecter/déconnecter/allumer/éteindre

Le cas VPN est remarquable car il peut offrir l'option "split", ce qui peut éviter de brouiller la connexion Docker pour cette cause. Mais le VPN fractionné n'empêchera pas toutes ces autres choses de tout gâcher.

J'utilise un câble RJ45 à l'ancienne...

Je ne comprends pas pourquoi docker-machine est si sensible à ces événements.

J'ai essayé de brancher/débrancher rj45, commutation wifi. Aucun problème de mon côté.

Pourrait-il y avoir un besoin de temps de traitement? Je continue à rencontrer cela avec une fonction shell qui fait:

docker-machine stop "${VM}"
docker-machine start "${VM}"
docker-machine ssh "${VM}" sudo /etc/init.docker restart
eval $(docker-machine env "${VM}"

Quand je fais ces commandes une à une, avec mes doigts, ça se passe bien. Mais lorsqu'elle est exécutée à partir du script, la même séquence de commandes fonctionne une fois, puis se bloque (ou prend plusieurs minutes).

En se connectant à docker-machine ls .

@jrep Ah, dans ce cas, oui, vous devez absolument attendre un bref intervalle pour que le démon démarre et commence à accepter les demandes. C'est pourquoi Machine a du code pour attendre Docker entre les redémarrages de notre démon pendant le provisionnement. On peut dire que nous devrions également vérifier cela sur start .

Ce numéro est très long et contient de nombreuses digressions. Si quelqu'un continue d'en rencontrer des similaires, veuillez en ouvrir un nouveau sur https://github.com/docker/machine/issues/new avec des informations détaillées, notamment :

• Sur quel système d'exploitation vous êtes
• Tout ce qui est atypique dans la configuration réseau (VPN, proxy, paramètres de configuration SSH, etc.),
• Sortie des commandes qui se comportent mal avec le drapeau --debug
• les journaux VirtualBox de ~/.docker/machine/machines/name/name .

Merci!

• N