Machine: докер-машина env xxx зависает навсегда

У меня аналогичная проблема с ОС Windows 7. вот суть файла журнала.

Я замечаю, что "docker-machine env machinename" также часто зависает, особенно когда он находится в моем ~ / .profile, заставляет новые терминалы зависать и не запускаться примерно в 50% случаев. В настоящее время просто ctrl + c 'запускает новую оболочку вкладки и порождает еще одну через 2 секунды, как правило, выполняет свою работу.

Трудно воспроизводить в новом / активном терминале, как правило, намного чаще при создании нового.

OSX 10.10.4, Docker Machine 0.3.0. Этих проблем не было в 0.2.x.

У меня такая же проблема со странным статусом выхода 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)"

Я могу воспроизвести эту проблему на MacOSX для драйвера виртуального бокса. Проблема обычно возникает, когда отсутствует маршрут к частной сети (тот, который используется docker cli).
В моем случае одна из причин, по которой я подозреваю, что этот маршрут отсутствует, заключается в том, что я использую VPN, которая имеет тенденцию портить маршруты частной сети. Исправить это можно, выполнив что-нибудь:

sudo route add -net 192.168.99.0/24 -interface vboxnet6

Где 192.168.99.0/24 - это сетевой диапазон, используемый boot2docker, а vboxnet6 - интерфейс, назначенный частной сети boot2docker.

Я пробовал решение @chantra , но не docker-machine прежнему зависает в новой оболочке с любой подкомандой. Однако прерывание с помощью ^C и повторная попытка работают.

Привет всем, всем, кто сталкивается с этой проблемой, одна из возможных проблем заключается в том, что демон Docker не запущен.

Не могли бы вы попробовать / вставить вывод следующих команд (это для виртуальных машин, на которых запущен boot2docker):

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

Спасибо!

@nathanleclaire, когда я пытаюсь запустить эту команду, она зависает здесь:

$ 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>}

Один раз, если закончится (если когда-нибудь), я вставлю, что дальше.

@inkel Хм, если он будет успешным, он должен работать почти сразу, так что если это займет больше нескольких секунд, что-то не так.

Он только что закончился:

SSH cmd err, output: <nil>:

Это заняло определенно больше нескольких секунд. Я снова бегаю с time чтобы узнать, сколько.

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

Если вы запустите:

$ /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

из интерфейса командной строки, что вы получите?

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> ~
$

Я думаю, что ошибся с предыдущим комментарием, это правильный вывод:

$ /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

Ммм ... через несколько минут на моем экране появилось следующее:

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 Odd. У вас есть VPN или какая-нибудь необычная настройка вашей сети, о которой вы можете подумать?

Нет, я не могу думать об этом. Несколько дней назад я все еще использовал 0.1.0 и работал отлично, затем обновился до 0.3.0 и он начал работать как сейчас. У меня есть еще один коллега, @fsaravia , который страдает той же проблемой.

@nathanleclaire после разговора с моим коллегой я обнаружил, что использую следующую версию, потому что версия в homebrew выдавала мне эту ошибку:

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

Он использует последнюю версию, поэтому я удалил эту версию, brew install docker-machine и теперь, похоже, она работает: smile_cat: извините за проблемы.

@inkel Отлично , рад, что у вас все получилось.

Я просто попробовал еще раз с самой последней версией docker-machine, но безуспешно. Я запускаю Windows 7 с оболочкой git. Все шаги и соответствующие результаты здесь .

Файл out.log содержит основные шаги. Затем есть docker-machine-create.log и docker-machine-env.log

После ручного копирования файлов сертификатов из / var / lib / boot2docker / tls / в /c/Users/Pedro/.docker/machine/machines/test/

Я сделал еще одну попытку, и в результате получился журнал docker-machine-env-2.log
Даже с экспортированными переменными среды в конце я все еще не могу подключиться.
docker ps завершился с ошибкой тайм-аута

Виртуальная машина запустилась, и служба докеров рушилась.
Я могу использовать ssh на машине, и служба докеров прослушивает правильный порт (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

Интересно то, что boot2docker отлично работает.
Еще мысли?
Спасибо.

Эту проблему действительно сложно воспроизвести ... После удаления всех vmboxnet_x, кроме vmboxnet0 и vmboxnet1, и перезагрузки компьютера (а не докер-машины) моя проблема исчезла.

После того, как мой компьютер несколько раз перешел в спящий режим, а затем повторил попытку, у меня возникла та же проблема. Когда у меня будет момент полностью перезапустить его, я попробую еще раз и посмотрю, что произойдет.

У меня есть последние версии всех приложений Docker. В течение нескольких недель у меня возникала проблема с Docker Machine на Linux Ubuntu, создающая виртуальные машины VirtualBox. Я только что добавил Docker Swarm, и проблема стала в несколько раз хуже (чаще). Я потратил два часа, пытаясь создать три роевые машины. Если я перезагружаюсь, это обычно исправляет, но это неразумно. Используя docker-machine --debug, вы можете увидеть, где он висит, как указывали другие комментаторы. Я вижу, что он зависает в нескольких местах с Daemon not responding yet: dial tcp 192.168.99.XXX:2376: no route to host , но в этот момент всегда происходит тайм-аут:

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 как выглядит конфигурация ssh вашего пользователя? см. https://github.com/docker/machine/issues/1591

Решение @chantra сработало для меня. действительно, причина заключалась в том, что мои маршруты затирались программным обеспечением VPN

Я только что столкнулся с этим, решение @chantra тоже сработало для меня. Cisco AnyConnect: ярость:

Также Cisco AnyConnect. Я не думаю, что вы могли бы добавить проверку, которая рекомендует исправить таблицу маршрутизации, если она была искажена таким программным обеспечением? ОЧЕНЬ неприятно ставить диагноз; Я все еще мог подключиться к докер-машине по ssh, которая успешно загрузилась, и мне пришлось просмотреть множество тикетов, прежде чем я нашел обсуждение в этом.

Я не думаю, что вы могли бы добавить проверку, которая рекомендует исправить таблицу маршрутизации, если она была искажена таким программным обеспечением?

На самом деле это именно то решение, которое я рассматриваю прямо сейчас. Во многих случаях кажется, что мы действительно можем успешно завершить создание экземпляра и получить IP-адрес, но он просто недоступен.

Еще у меня проблема недоступности докера после сна .

Как бы вы применили решение

Я испытал эту проблему также после нескольких снов.
перезапуск устранил проблему.

Это случилось и со мной, когда у меня запущена докер-машина, а затем я подключаюсь к VPN, команда просто зависает навсегда.
Однако я отключился от VPN, перезапустил машину docker-machine restart <MACHINE-NAME> и он снова начал работать.

Это случилось и со мной, когда у меня запущена докер-машина, а затем я подключаюсь к VPN, команда просто зависает навсегда.
Однако я отключился от VPN, перезапустил машину, перезапустил докер-машинуи он снова заработал.

Это случилось и со мной: у меня была запущена докер-машина, я подключился к VPN, отключился от VPN, и docker env <MACHINE-NAME> зависает

Однако я сделал docker-machine restart <MACHINE-NAME> и это не помогло - docker env <MACHINE-NAME> все еще висит.

У меня тоже есть эта проблема в Mac OS 10.10.4 с Cisco AnyConnect VPN.

• Свежая загрузка, докер работает нормально
• иди на VPN, отключайся
• docker-machine env default просто зависает

Пытался перезапустить докер-машину по умолчанию, проблема не устранена.

Решение @chantra , похоже, работает для меня. На моей машине интерфейс был vboxnet0 (обнаружен с помощью ifconfig из терминала Mac). Это проще, чем перезагружать каждый раз, когда мне нужно подключиться к VPN.

Не уверен, что я прокомментировал, какой VPN я использую, но FWIW, я также использую cisco
anyconnect ....

В среду, 23 сентября 2015 г., в 19:52, Джо МакГлинн [email protected]
написал:

У меня тоже есть эта проблема в Mac OS 10.10.4 с Cisco AnyConnect
VPN.

• Свежая загрузка, докер работает нормально
• иди на VPN, отключайся
• docker-machine env default просто зависает

Пытался перезапустить докер-машину по умолчанию, проблема не устранена.

Решение @chantra https://github.com/chantra , похоже, работает для меня. На
на моей машине интерфейс был vboxnet0 (найден с помощью ifconfig с Mac
терминал) Это проще, чем перезагружать каждый раз, когда мне нужно подключиться к VPN.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/1500#issuecomment -142788894.

FWIW Я также использовал Cisco AnyConnect VPN, в OS X 10.10.5 я просто попробовал openconnect вместо этого, и это, кажется, позволяет избежать проблемы.

@ronen , Спасибо за отзыв об openconnect, я никогда не знал, что он существует. Прощай, AnyConnect: ухмыляется:

@ChrisRut да, я только что узнал об openconnect, когда пытался решить эту проблему. Доброго времени суток, AnyConnect! Я обнаружил, что openconnect немного неудобен в использовании, поэтому я собрал быструю оболочку, которая позволяет вам просто набирать «vpn up» и «vpn down». Это на https://gist.github.com/ronen/7d486adbde5d6bfd2472, если вам интересно

Поскольку кажется, что у нас есть несколько проблем с аналогичными симптомами, я открыл # 1934 для тех, кто испытывает проблемы на хостах Windows 10 (или, возможно, других версиях) после сна. Чтобы разделить опасения, я предлагаю связать заголовок этого выпуска с проблемами сети VPN.

У меня возникает эта проблема после того, как моя главная машина переходит в спящий режим, и я возвращаюсь к ней позже. В конечном итоге я удаляю все из своей папки c: usersdan.dockermachine (кроме кеша), а затем заново все это создаю. Это быстрее, чем перезагрузка хост-машины! ;)

О, и я также должен убить некоторые процессы перед тем, как это сделать. Я обычно использую 3 процесса VBoxHeadless.exe, 3 процесса VBoxNetDHCP.exe и интерфейс VirtualBox.

Я разбудил свой ноутбук и удалил экземпляр докер-машины с именем «dev».
Я выполнил следующие команды, чтобы создать две новые виртуальные машины:

$ 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)

docker-machine env dev --shell=bash зависает на несколько минут и выгружает в stderr следующее:

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

Вывод журнала stdout можно найти в этом Gist .

Странно то, что правильный вывод сбрасывается после достижения максимального количества повторных попыток, см. Конец журнала.

Это рассчитанный по времени вывод stdout:

$ 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

И это становится все страннее ...
Та же команда для первой виртуальной машины выполняется без каких-либо проблем:

$ 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 Если вы добавите завершающую косую черту к параметрам * PROXY, например, --engine-env HTTP_PROXY=http://10.206.246.20:8080/ , будет ли это успешно или продолжится неудача?

Я получаю это прямо сейчас на Debian 8.2.

Добавьте Jupiter Junos Pulse в список программного обеспечения VPN, которое, по-видимому, вызывает эту проблему.

Мне кажется вероятным, что это будут делать _любые_ VPN, поскольку все они имеют одно и то же фундаментальное определение, отменяющее "обычную" маршрутизацию.

Обновление: используя «разделенное соединение» (вариант, который позволяет моя установка. Путем подключения к другому серверу VPN), я, кажется, избегаю этого.

Чего ждать? Я не использую ни VPN, ни прокси ...

VPN - это лишь одна из многих вещей, которые мешают настройке сети. В более общем плане, любое изменение сетевых подключений может (включая некоторые вещи, которые вы можете не воспринимать как «сеть»):

• Включение / отключение VPN
• Подключение / отключение проводной ЛВС
• Включение / отключение Wi-Fi / изменение зоны (например, перенос ноутбука в другую часть здания)
• Подключение / отключение устройства Bluetooth (из-за Bluetooth PAN )
• даже USB-устройство подключить / отключить / включить / выключить

Случай с VPN примечателен тем, что он может предлагать вариант «разделения», который может избежать сбоя соединения Docker по этой причине. Но разделенный VPN не предотвратит испорченность всего остального.

Я использую старый кабель RJ45 ...

Я не понимаю, почему докер-машина так чувствительна к этим событиям.

Пробовал подключать / отключать rj45, переключение Wi-Fi. С моей стороны нет проблем.

Может потребоваться некоторое время на обработку? Я продолжаю сталкиваться с этим с помощью функции оболочки, которая:

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

Когда я выполняю эти команды пальцами по одной, все идет нормально. Но при запуске из скрипта та же последовательность команд срабатывает один раз, затем зависает (или занимает несколько минут).

При подключении к @mrumpf эта виртуальная машина является второй в моем списке docker-machine ls .

@jrep А, в таком случае, да, вам определенно нужно подождать некоторое время, пока демон запустится и начнет принимать запросы. Вот почему у Machine есть код для ожидания Docker между перезапусками нашего демона во время подготовки. Возможно, мы должны проверить это и на start .

Этот выпуск очень длинный и содержит много отступлений. Если кто-то продолжает встречать похожие, пожалуйста, откройте новый на https://github.com/docker/machine/issues/new с подробной информацией, включая:

• На какой ОС вы работаете
• Все, что нетипично в сетевой конфигурации (VPN, прокси, настройки конфигурации SSH и т. Д.),
• Вывод некорректных команд с флагом --debug
• журналы VirtualBox из ~/.docker/machine/machines/name/name .

Спасибо!

• N