Machine: docker-machine env xxx hängt für immer

Ich habe ein ähnliches Problem mit Windows 7 OS. Hier ist eine Zusammenfassung der Log-Datei.

Ich bemerke auch, dass "docker-machine env machinename" häufig hängt, besonders wenn es in meinem ~/.profile ist, führt dazu, dass neue Terminals hängen und nicht in 50% der Fälle gestartet werden. Derzeit genügt es, die neue Tab-Shell mit Strg + c zu drücken und 2 Sekunden später eine weitere zu starten.

Schwierig in einem neuen/aktiven Terminal zu reproduzieren, neigt dazu, viel häufiger zu sein, wenn ein neues gespawnt wird.

OSX 10.10.4, Docker-Maschine 0.3.0. Diese Probleme waren in 0.2.x nicht vorhanden.

Ich habe das gleiche Problem mit dem seltsamen Exit-Status 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)"

Ich kann dieses Problem unter MacOSX für den Virtualbox-Treiber reproduzieren. Das Problem tritt normalerweise auf, wenn die Route zum privaten Netzwerk fehlt (die von docker cli verwendet wird).
In meinem Fall vermute ich, dass diese Route fehlt, weil ich ein VPN verwende, das dazu neigt, private Netzwerkrouten durcheinander zu bringen. Eine Lösung hierfür besteht darin, etwas mitzulaufen:

sudo route add -net 192.168.99.0/24 -interface vboxnet6

Dabei ist 192.168.99.0/24 der von boot2docker verwendete Netzwerkbereich und vboxnet6 die Schnittstelle, die dem privaten boot2docker-Netzwerk zugewiesen ist.

Ich habe die Lösung von @chantra ausprobiert, aber nicht den Trick gemacht, docker-machine hängt immer noch in einer neuen Shell mit einem Unterbefehl. Mit ^C unterbrechen und es erneut zu versuchen, funktioniert jedoch.

Hallo zusammen, jeder, der auf dieses Problem stößt, ist eines der möglichen Probleme, dass der Docker-Daemon nicht ausgeführt wird.

Können Sie bitte die Ausgabe der folgenden Befehle versuchen / einfügen (dies gilt für VMs, auf denen boot2docker ausgeführt wird):

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

Vielen Dank!

@nathanleclaire Wenn ich versuche, diesen Befehl auszuführen, hängt er hier:

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

Sobald es fertig ist (falls es jemals passiert), werde ich einfügen, was als nächstes kommt.

@inkel Hm, es sollte so ziemlich sofort laufen, wenn es erfolgreich sein soll. Wenn es also länger als ein paar Sekunden dauert, stimmt etwas nicht.

Es ist gerade fertig geworden mit:

SSH cmd err, output: <nil>:

Es hat definitiv mehr als ein paar Sekunden gedauert. Ich laufe wieder mit time zu sehen, wie viel.

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

Wenn du läufst :

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

von der CLI selbst, was bekommen Sie?

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

Ich glaube, ich habe einen Fehler mit meinem vorherigen Kommentar gemacht, dies ist die richtige Ausgabe:

$ /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... nach ein paar Minuten erschien folgendes auf meinem Bildschirm:

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 Seltsam . Haben Sie ein VPN oder eine ungewöhnliche Einrichtung, die Sie sich für Ihr Netzwerk vorstellen können?

Nein, das fällt mir nicht ein. Vor ein paar Tagen benutzte ich noch 0.1.0 und funktionierte perfekt, dann aktualisierte ich auf 0.3.0 und es fing an, funky wie derzeit zu funktionieren. Ich habe einen anderen Kollegen, @fsaravia , der das gleiche Problem hat.

@nathanleclaire Nachdem ich mit meinem Kollegen gesprochen hatte, habe ich festgestellt, dass ich die folgende Version verwende, weil die in Homebrew mir diesen Fehler gab:

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

Er benutzt die neueste Version, also habe ich diese Version gelöscht, brew install docker-machine und jetzt scheint sie zu funktionieren :smile_cat: Entschuldigung für die Mühe.

@inkel Schön, schön, dass es funktioniert.

Ich habe es gerade noch einmal mit der neuesten Version von docker-machine versucht, ohne Erfolg. Ich verwende Windows 7 mit Git-Shell. Alle Schritte und entsprechenden Ausgaben sind hier .

Die Datei out.log enthält die wichtigsten Schritte. Dann gibt es noch eine docker-machine-create.log und eine docker-machine-env.log

Nach dem manuellen Kopieren der Zertifikatsdateien von /var/lib/boot2docker/tls/ nach /c/Users/Pedro/.docker/machine/machines/test/

Ich habe einen weiteren Versuch gemacht und das resultierende Protokoll ist docker-machine-env-2.log
Selbst mit den exportierten Umgebungsvariablen am Ende kann ich immer noch keine Verbindung herstellen.
docker ps mit Zeitüberschreitungsfehler beendet

Die VM wurde gestartet und der Docker-Dienst ruiniert.
Ich kann auf dem Computer ssh und der Docker-Dienst hört auf dem richtigen 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

Das Interessante ist, dass boot2docker gut funktioniert.
Noch mehr Gedanken?
Vielen Dank.

Dieses Problem ist wirklich schwer zu reproduzieren... Nachdem ich alle vmboxnet_x außer vmboxnet0 und vmboxnet1 gelöscht und den Computer (anstatt docker-machine) neu gestartet habe, war mein Problem verschwunden.

Nachdem ich meinen Computer ein paar Mal in den Ruhezustand versetzt und es dann erneut versucht habe, habe ich das gleiche Problem. Wenn ich einen Moment hatte, um es vollständig neu zu starten, werde ich es erneut versuchen und sehen, was passiert.

Ich habe die neuesten Versionen aller Docker-Apps. Ich habe das Problem seit Wochen mit Docker Machine auf Linux Ubuntu beim Erstellen von VirtualBox-VMs ein- und ausgeschaltet. Ich habe gerade Docker Swarm hinzugefügt und das Problem wurde mehrmals schlimmer (häufiger). Ich habe zwei Stunden damit verbracht, drei Schwarmmaschinen zu erstellen. Wenn ich neu starte, wird es normalerweise behoben, aber das ist nicht vernünftig. Wenn Sie --debug von docker-machine verwenden, können Sie sehen, wo es hängt, wie andere Kommentatoren darauf hingewiesen haben. Ich sehe, dass es an einigen Stellen bei Daemon not responding yet: dial tcp 192.168.99.XXX:2376: no route to host hängt, aber die Zeitüberschreitung tritt immer an dieser Stelle auf:

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 wie sieht die https://github.com/docker/machine/issues/1591

Die Lösung von @chantra hat bei mir funktioniert. Tatsächlich war die Ursache dafür, dass meine Routen von VPN-Software überlastet wurden

Ich bin auch gerade darauf gestoßen , die Lösung von

Auch Cisco AnyConnect. Ich nehme an, Sie könnten keinen Check hinzufügen, der empfiehlt, die Routing-Tabelle zu reparieren, wenn sie von einer solchen Software verstümmelt wurde? Es ist SEHR frustrierend zu diagnostizieren; Ich konnte mich immer noch per ssh in den Docker-Rechner einloggen, der erfolgreich gebootet wurde, und musste mir viele Tickets ansehen, bevor ich die Diskussion in diesem fand.

Ich nehme an, Sie könnten keinen Check hinzufügen, der empfiehlt, die Routing-Tabelle zu reparieren, wenn sie von einer solchen Software verstümmelt wurde?

Das ist eigentlich genau die Lösung, die ich gerade überlege. In vielen Fällen scheint es, dass wir die Erstellung der Instanz tatsächlich erfolgreich abschließen und eine IP-Adresse erhalten können, die jedoch nicht erreichbar ist.

Ich habe auch das Problem des unerreichbaren Dockers nach dem Einschlafen .

Wie würden Sie die Lösung von @chantra in Windows 10

Ich hatte dieses Problem auch nach mehrmaligem Schlafen.
Neustart hat das Problem behoben..

Das ist mir auch passiert, wenn ich eine Docker-Maschine laufen habe und dann auf ein VPN komme, der Befehl hängt einfach für immer.
Ich bin jedoch aus dem VPN ausgestiegen, hat docker-machine restart <MACHINE-NAME> gestartet und es funktionierte wieder.

Das ist mir auch passiert, wenn ich eine Docker-Maschine laufen habe und dann auf ein VPN komme, der Befehl hängt einfach für immer.
Ich bin jedoch aus dem VPN ausgestiegen und habe den Docker-Computer-Neustart der Maschine neu gestartetund es fing wieder an zu funktionieren.

Das ist mir auch gerade passiert: Ich hatte eine Docker-Maschine, bin auf VPN eingestiegen, VPN ausgestiegen und docker env <MACHINE-NAME> hängt sich auf

Ich habe jedoch docker-machine restart <MACHINE-NAME> und es hat nicht geholfen - docker env <MACHINE-NAME> hängt immer noch.

Ich habe dieses Problem auch unter Mac OS 10.10.4 mit dem Cisco AnyConnect VPN.

• Frischer Boot, Docker funktioniert einwandfrei
• geh auf das VPN, zieh dich zurück
• docker-machine env default bleibt einfach hängen

Der Neustart des Docker-Computers wurde standardmäßig versucht, das Problem besteht weiterhin.

Die Lösung von @chantra scheint für mich zu funktionieren. Auf meinem Computer war die Schnittstelle vboxnet0 (mit ifconfig vom Mac-Terminal gefunden) Viel einfacher als jedes Mal neu zu starten, wenn ich auf das VPN gehen muss.

Ich bin mir nicht sicher, ob ich kommentiert hatte, welches VPN ich verwende, aber FWIW, ich benutze auch Cisco
irgendwie verbinden....

Am Mittwoch, den 23. September 2015 um 19:52 Uhr, Joe McGlynn [email protected]
schrieb:

Ich habe dieses Problem auch unter Mac OS 10.10.4 mit Cisco AnyConnect
VPN.

• Frischer Boot, Docker funktioniert einwandfrei
• geh auf das VPN, zieh dich zurück
• docker-machine env default bleibt einfach hängen

Der Neustart des Docker-Computers wurde standardmäßig versucht, das Problem besteht weiterhin.

@chantra https://github.com/chantra 's Lösung scheint für mich zu funktionieren. Auf
Meine Maschine war die Schnittstelle vboxnet0 (gefunden mit ifconfig vom Mac
Terminal) Viel einfacher als jedes Mal neu zu starten, wenn ich auf das VPN gehen muss.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/machine/issues/1500#issuecomment -142788894.

FWIW Ich habe auch Cisco AnyConnect VPN verwendet, unter OS X 10.10.5 habe ich stattdessen einfach Openconnect versucht und es scheint das Problem zu vermeiden.

@ronen , Danke für den Tipp zu openconnect, ich wusste nie, dass es das gibt. Auf Wiedersehen AnyConnect :grins:

@ChrisRut ja, ich habe gerade von Openconnect erfahren, als ich versucht habe, dieses Problem zu lösen. Auf Wiedersehen AnyConnect! Ich fand Openconnect jedoch etwas umständlich, also habe ich einen schnellen Wrapper zusammengestellt, mit dem Sie einfach "vpn up" und "vpn down" eingeben können. Bei Interesse unter https://gist.github.com/ronen/7d486adbde5d6bfd2472

Da es anscheinend mehrere Probleme mit ähnlichen Symptomen gibt, habe ich #1934 für diejenigen geöffnet, die nach dem Ruhezustand Probleme auf Windows 10-Hosts (oder möglicherweise anderen Versionen) haben. Um Bedenken zu trennen, schlage ich vor, den Titel dieser Ausgabe auf VPN-Netzwerkprobleme zu beziehen.

Ich bekomme dieses Problem, nachdem mein Host-Rechner in den Ruhezustand gegangen ist, und ich komme später darauf zurück. Am Ende lösche ich alles aus meinem c:usersdan.dockermachine-Ordner (außer dem Cache) und erstelle dann alles neu. Das geht schneller, als den Host-Rechner neu zu starten! ;)

Oh, und ich muss auch einige Prozesse beenden, bevor ich das tue. Ich neige dazu, 3 'VBoxHeadless.exe'-Prozesse, 3 'VBoxNetDHCP.exe' und ein 'VirtualBox Interface' zu haben.

Ich habe mein Notebook aufgeweckt und eine Docker-Maschinen-Instanz mit dem Namen "dev" gelöscht.
Ich habe die folgenden Befehle ausgeführt, um zwei neue virtuelle Maschinen zu erstellen:

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

Das docker-machine env dev --shell=bash hängt für einige Minuten und gibt folgendes nach stderr aus:

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

Die stdout-Protokollausgabe finden Sie in diesem Gist .

Das Seltsame ist, dass die korrekte Ausgabe nach Erreichen der maximalen Anzahl von Wiederholungen gedumpt wird, siehe das Ende des Protokolls.

Dies ist die zeitgesteuerte Standardausgabe:

$ 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

Und es wird immer seltsamer...
Der gleiche Befehl für die erste virtuelle Maschine wird ohne Probleme ausgeführt:

$ 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 Wenn Sie den *PROXY-Optionen einen nachgestellten Schrägstrich hinzufügen, z. B. --engine-env HTTP_PROXY=http://10.206.246.20:8080/ , ist dies erfolgreich oder schlägt es weiterhin fehl?

Ich bekomme das gerade auf Debian 8.2.

Fügen Sie Jupiter Junos Pulse zur Liste der VPN-Software hinzu, die dieses Problem zu verursachen scheint.

Es scheint mir wahrscheinlich, dass _any_ VPN dies tun würde, da sie alle die gleiche grundlegende Definition haben, um das "normale" Routing zu überschreiben.

Update: Durch die Verwendung einer "geteilten Verbindung" (eine Option, die meine Installation zulässt, indem ich mich mit einem anderen VPN-Server verbinde), scheine ich dies zu vermeiden.

Warte was? Ich verwende keine Art von VPN oder Proxy...

VPN ist nur eines von vielen Dingen, die die Netzwerkkonfiguration durcheinander bringen. Allgemeiner gesagt kann jede Änderung der Netzwerkverbindungen (und dazu gehören einige Dinge, die Sie möglicherweise nicht als "Netzwerk" bezeichnen):

• VPN aktivieren/deaktivieren
• Kabelgebundenes LAN verbinden/trennen
• WLAN aktivieren / deaktivieren / Zonenwechsel (wie das Tragen eines Laptops in einen anderen Bereich des Gebäudes)
• Bluetooth-Gerät verbinden/trennen (wegen Bluetooth PAN )
• sogar USB-Gerät verbinden/trennen/ein/aus

Der VPN-Fall ist bemerkenswert, da er möglicherweise die Option "Split" bietet, die eine Überlastung der Docker-Verbindung aus dieser Ursache vermeiden kann. Aber Split VPN wird nicht verhindern, dass all diese anderen Dinge die Dinge durcheinander bringen.

Ich verwende ein altmodisches RJ45-Kabel...

Ich verstehe nicht, warum Docker-Maschine so empfindlich auf diese Ereignisse reagiert.

Ich habe versucht, RJ45 ein- und ausstecken, WLAN-Umschaltung. Kein Problem auf meiner Seite.

Könnte eine Bearbeitungszeit erforderlich sein? Ich laufe immer wieder mit einer Shell-Funktion darauf ein, die Folgendes tut:

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

Wenn ich diese Befehle einzeln mit meinen Fingern ausführe, geht es gut. Aber wenn sie aus dem Skript ausgeführt wird, funktioniert dieselbe Befehlssequenz einmal, dann hängt sie (oder dauert mehrere Minuten).

Diese VM, die sich mit @mrumpf verbindet , ist die zweite in meiner docker-machine ls Liste.

@jrep Ah, in diesem Fall müssen Sie auf jeden Fall ein kurzes Intervall warten, bis der Daemon startet und Anfragen akzeptiert. Aus diesem Grund verfügt Machine über Code, der zwischen unseren Daemon-Neustarts während der Bereitstellung auf Docker wartet. Das sollten wir wohl auch bei start überprüfen.

Diese Ausgabe ist sehr lang und enthält viele Abschweifungen. Wenn jemand weiterhin auf ähnliche stößt, öffnen Sie bitte eine neue unter https://github.com/docker/machine/issues/new mit detaillierten Informationen, einschließlich:

• Welches Betriebssystem hast du?
• Alles Untypische in der Netzwerkkonfiguration (VPN, Proxy, SSH-Konfigurationseinstellungen usw.),
• Ausgabe der fehlerhaften Befehle mit dem --debug Flag
• die VirtualBox-Protokolle von ~/.docker/machine/machines/name/name .

Vielen Dank!

• n