Machine: डॉकर-मशीन एनवी xxx हमेशा के लिए लटक जाता है

मेरे पास विंडोज 7 ओएस के साथ समान समस्या है। यहाँ लॉग फ़ाइल का सार है।

मैं देख रहा हूं कि "डॉकर-मशीन एनवी मशीननाम" बहुत अधिक लटका हुआ है, खासकर जब यह मेरे ~/.प्रोफाइल में है, तो नए टर्मिनलों को लटका दिया जाता है और लगभग 50% समय शुरू नहीं होता है। वर्तमान में सिर्फ ctrl+c'ing नया टैब खोल रहा है, और एक और 2 सेकंड बाद में स्पॉन करने से काम हो जाता है।

एक नए/सक्रिय टर्मिनल में पुन: पेश करना मुश्किल है, एक नया पैदा करते समय अधिक बार होता है।

ओएसएक्स 10.10.4, डॉकर मशीन 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 पर इस समस्या को पुन: पेश करने में सक्षम हूं। समस्या आमतौर पर तब होती है जब निजी नेटवर्क का मार्ग गायब होता है (डॉकर क्ली द्वारा उपयोग किया जाने वाला)।
मेरे मामले में, मुझे संदेह है कि इस मार्ग के गायब होने का एक कारण यह है कि मैं एक वीपीएन का उपयोग कर रहा हूं जो निजी नेटवर्क मार्गों के साथ खिलवाड़ करता है। इसके लिए एक फिक्स कुछ साथ चलाना है:

sudo route add -net 192.168.99.0/24 -interface vboxnet6

जहां 192.168.99.0/24 boot2docker द्वारा उपयोग की जाने वाली नेटवर्क रेंज है और vboxnet6 बूट

मैंने @chantra के समाधान की कोशिश की है लेकिन चाल नहीं की है, docker-machine किसी भी उपकमांड के साथ एक नए खोल में अभी भी लटकता है। हालांकि, ^C साथ बाधा डालना और फिर से प्रयास करना काम करता है।

हाय सब, जो कोई भी इस मुद्दे का सामना कर रहा है, खेल में संभावित मुद्दों में से एक यह है कि डॉकर डेमॉन नहीं चल रहा है।

क्या आप कृपया निम्न कमांड के आउटपुट को पेस्ट/पेस्ट कर सकते हैं (यह boot2docker चलाने वाले VMs के लिए है):

$ 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

CLI से अपने आप, आपको क्या मिलता है?

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 अजीब। क्या आपके पास एक वीपीएन या कोई असामान्य सेटअप है जहाँ तक आपका नेटवर्क जाता है जिसके बारे में आप सोच सकते हैं?

नहीं, ऐसा नहीं है कि मैं सोच सकता हूं। कुछ दिन पहले मैं अभी भी 0.1.0 का उपयोग कर रहा था और पूरी तरह से काम किया, फिर 0.3.0 अपडेट किया और यह वर्तमान में फंकी काम करना शुरू कर दिया। मेरे पास एक और सहकर्मी है, @fsaravia , जो एक ही समस्या से पीड़ित है।

@nathanleclaire अपने सहयोगी के साथ बात करने के बाद मैंने पाया है कि मैं निम्नलिखित संस्करण का उपयोग कर रहा था, 'क्योंकि होमब्रे में से एक मुझे यह त्रुटि दे रहा था:

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

वह नवीनतम का उपयोग कर रहा है, इसलिए मैंने उस संस्करण को हटा दिया, brew install docker-machine और अब काम करने लगता है: मुस्कान_कैट: परेशानी के लिए खेद है।

@inkel अच्छा, खुशी है कि आप इसे काम कर रहे हैं।

मैंने बिना किसी सफलता के डॉकर-मशीन के नवीनतम संस्करण के साथ फिर से प्रयास किया। मैं विंडोज 7 पर गिट खोल के साथ चल रहा हूं। सभी चरण और संबंधित आउटपुट यहां हैं ।

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 कर सकता हूँ और docker सेवा सही पोर्ट पर सुन रही है (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 ठीक काम करता है।
कोई और विचार?
धन्यवाद।

यह समस्या वास्तव में पुन: उत्पन्न करना कठिन है ... vmboxnet0 और vmboxnet1 को छोड़कर सभी vmboxnet_x को हटाने और कंप्यूटर को रिबूट करने के बाद (डॉकर-मशीन के बजाय), मेरी समस्या दूर हो गई थी।

अपने कंप्यूटर को एक-दो बार सोने के लिए रखने के बाद और फिर से कोशिश करने के बाद मुझे वही समस्या होने लगी है। जब मेरे पास इसे पूरी तरह से पुनः आरंभ करने का क्षण था तो मैं फिर से कोशिश करूंगा और देखूंगा कि क्या होता है।

मेरे पास सभी डॉकर ऐप्स के नवीनतम संस्करण हैं। मैंने लिनक्स उबंटू बिल्डिंग वर्चुअलबॉक्स वीएम पर डॉकर मशीन के साथ हफ्तों तक इस मुद्दे को चालू और बंद कर दिया है। मैंने अभी डॉकर झुंड जोड़ा है और समस्या कई गुना खराब हो गई है (अधिक बार)। मैंने तीन झुंड मशीन बनाने की कोशिश में दो घंटे बिताए हैं। अगर मैं रीबूट करता हूं तो यह आमतौर पर इसे ठीक करता है, लेकिन यह उचित नहीं है। डॉकर-मशीन के --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 config कैसा दिखता है? देखें: https://github.com/docker/machine/issues/1591

@chantra के समाधान ने मेरे लिए काम किया। वास्तव में, इसका कारण मेरे मार्गों को वीपीएन सॉफ्टवेयर द्वारा बंद किया जा रहा था

मैं बस इसमें भी भाग गया, @chantra के समाधान ने मेरे लिए भी काम किया। सिस्को एनीकनेक्ट: क्रोध:

सिस्को एनीकनेक्ट भी। मुझे नहीं लगता कि आप एक चेक जोड़ सकते हैं जो रूटिंग टेबल को ठीक करने की सिफारिश करता है अगर इसे इस तरह के सॉफ़्टवेयर द्वारा खराब कर दिया गया है? निदान करने में बहुत निराशा होती है; मैं अभी भी डॉकर मशीन में ssh करने में सक्षम था, जो सफलतापूर्वक बूट हो गया था, और इससे पहले कि मैं इस एक में चर्चा पाता, कई टिकटों को देखना पड़ा।

मुझे नहीं लगता कि आप एक चेक जोड़ सकते हैं जो रूटिंग टेबल को ठीक करने की सिफारिश करता है अगर इसे इस तरह के सॉफ़्टवेयर द्वारा खराब कर दिया गया है?

यह वास्तव में सटीक समाधान है जिस पर मैं अभी विचार कर रहा हूं। कई मामलों में, ऐसा लगता है कि हम वास्तव में इंस्टेंस के निर्माण को सफलतापूर्वक पूरा कर सकते हैं और एक आईपी पता प्राप्त कर सकते हैं, ऐसा होता है कि यह पहुंच योग्य नहीं होता है।

मुझे नींद के बाद अगम्य डॉकटर की भी

आप विंडोज 10 में @chantra का समाधान कैसे करेंगे?

मैंने कई नींदों के बाद भी इस मुद्दे का अनुभव किया।
पुनरारंभ करने से समस्या ठीक हो गई ..

मेरे साथ भी ऐसा हुआ था जब मेरे पास डॉकटर-मशीन चल रही थी और फिर मैं एक वीपीएन पर मिलता हूं, कमांड हमेशा के लिए हैंग हो जाता है।
हालाँकि, मैं वीपीएन से उतर गया मशीन ने docker-machine restart <MACHINE-NAME> पुनरारंभ किया और यह फिर से काम करना शुरू कर दिया।

मेरे साथ भी ऐसा हुआ था जब मेरे पास डॉकटर-मशीन चल रही थी और फिर मैं एक वीपीएन पर मिलता हूं, कमांड हमेशा के लिए हैंग हो जाता है।
हालाँकि, मैंने वीपीएन बंद कर दिया मशीन को पुनरारंभ किया docker- मशीन पुनरारंभऔर यह फिर से काम करना शुरू कर दिया।

यह मेरे साथ भी हुआ: मेरे पास डॉकर-मशीन चल रहा था, वीपीएन पर मिला, वीपीएन बंद हो गया, और docker env <MACHINE-NAME> हैंग हो गया

हालाँकि मैंने docker-machine restart <MACHINE-NAME> और इससे कोई फायदा नहीं हुआ - docker env <MACHINE-NAME> अभी भी लटका हुआ है।

मुझे सिस्को एनीकनेक्ट वीपीएन के साथ मैक ओएस 10.10.4 पर भी यह समस्या हो रही है।

• ताजा बूट, डोकर ठीक काम करता है
• वीपीएन पर जाएं, पीछे जाएं
• डॉकर-मशीन एनवी डिफ़ॉल्ट बस लटकता है

डॉकर-मशीन पुनरारंभ डिफ़ॉल्ट का प्रयास किया, समस्या बनी रहती है।

@chantra का समाधान मेरे लिए काम करता प्रतीत होता है। मेरी मशीन पर इंटरफ़ेस vboxnet0 था (मैक टर्मिनल से ifconfig का उपयोग करके पाया गया) हर बार जब मुझे वीपीएन पर जाने की आवश्यकता होती है तो रीबूट करने से कहीं ज्यादा आसान होता है।

मुझे यकीन नहीं है कि मैंने टिप्पणी की थी कि मैं किस वीपीएन का उपयोग कर रहा था, लेकिन एफडब्ल्यूआईडब्ल्यू, मैं सिस्को का भी उपयोग कर रहा हूं
कोई भी कनेक्ट ....

बुधवार, 23 सितंबर, 2015 को शाम 7:52 बजे, जो मैकग्लिन सूचनाएं @github.com
लिखा था:

मुझे यह समस्या मैक ओएस 10.10.4 पर सिस्को एनीकनेक्ट के साथ भी आ रही है
वीपीएन.

• ताजा बूट, डोकर ठीक काम करता है
• वीपीएन पर जाएं, पीछे जाएं
• डॉकर-मशीन एनवी डिफ़ॉल्ट बस लटकता है

डॉकर-मशीन पुनरारंभ डिफ़ॉल्ट का प्रयास किया, समस्या बनी रहती है।

@chantra https://github.com/chantra का समाधान मेरे लिए काम करता प्रतीत होता है। पर
मेरी मशीन इंटरफ़ेस vboxnet0 था (मैक से ifconfig का उपयोग करके पाया गया
टर्मिनल) हर बार जब मुझे वीपीएन पर जाने की आवश्यकता होती है तो रिबूट करने से कहीं ज्यादा आसान होता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/machine/issues/1500#issuecomment -142788894।

एफडब्ल्यूआईडब्ल्यू मैं ओएस एक्स 10.10.5 पर सिस्को एनीकनेक्ट वीपीएन का भी उपयोग कर रहा था, मैंने इसके बजाय ओपनकनेक्ट की कोशिश की और ऐसा लगता है कि समस्या से बचने के लिए।

@ronen ,

@ChrisRut हाँ, मैंने इस समस्या को हल करने का प्रयास करते समय ओपनकनेक्ट के बारे में सीखा। अलविदा AnyConnect वास्तव में! हालांकि मैंने ओपनकनेक्ट को उपयोग करने के लिए थोड़ा बोझिल पाया, इसलिए मैंने एक त्वरित रैपर को एक साथ फेंक दिया जो आपको "वीपीएन अप" और "वीपीएन डाउन" टाइप करने देता है। यदि आप रुचि रखते हैं तो यह https://gist.github.com/ronen/7d486adbde5d6bfd2472 पर है

जैसा कि ऐसा लगता है कि हमारे पास समान लक्षणों पर कई मुद्दे हैं, मैंने उन लोगों के लिए #1934 खोला जो नींद के बाद विंडोज 10 (या शायद अन्य संस्करण) होस्ट पर समस्याओं का अनुभव करते हैं। चिंताओं को अलग करने के लिए, मैं कृपया इस मुद्दे के शीर्षक को वीपीएन नेटवर्क मुद्दों से संबंधित करने का सुझाव देता हूं।

मेरी मेजबान मशीन के सो जाने के बाद मुझे यह समस्या आती है, और मैं बाद में इस पर वापस आता हूं। मैं अपने c:usersdan.dockermachine फ़ोल्डर (कैश के अलावा) से सब कुछ हटा देता हूं, फिर इसे फिर से बनाएं। यह होस्ट मशीन को रिबूट करने की तुलना में तेज है! ;)

ओह, और मुझे ऐसा करने से पहले कुछ प्रक्रियाओं को भी मारना है। मेरे पास 3 'VBoxHeadless.exe' प्रक्रियाएं, 3 'VBoxNetDHCP.exe' और एक 'वर्चुअलबॉक्स इंटरफ़ेस' है।

मैंने अपनी नोटबुक को जगाया और "देव" नाम से एक डॉकटर-मशीन इंस्टेंस को हटा दिया।
मैंने दो नई वर्चुअल मशीन बनाने के लिए निम्न आदेश चलाए:

$ 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

इस सार में स्टडआउट लॉग आउटपुट पाया जा सकता है।

अजीब बात यह है कि अधिकतम पुनर्प्रयासों तक पहुंचने के बाद सही आउटपुट डंप किया जाता है, लॉग का अंत देखें।

यह समयबद्ध स्टडआउट आउटपुट है:

$ 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/ पिछला स्लैश जोड़ते हैं, तो क्या यह सफल होता है या असफल होता रहता है?

मुझे यह अभी डेबियन 8.2 पर मिल रहा है।

जुपिटर जूनोस पल्स को वीपीएन सॉफ्टवेयर की सूची में जोड़ें जो इस समस्या का कारण लगता है।

यह मुझे इस संभावना के रूप में मारता है कि _any_ वीपीएन ऐसा करेगा, क्योंकि उन सभी के पास "साधारण" रूटिंग को ओवरराइड करने के लिए एक ही मौलिक परिभाषा है।

अद्यतन: एक "विभाजित कनेक्शन" (एक विकल्प जो मेरी स्थापना की अनुमति देता है। एक अलग वीपीएन सर्वर से कनेक्ट करके) का उपयोग करके, मैं इससे बचता हूं।

किसकी प्रतीक्षा? मैं किसी भी प्रकार के वीपीएन या प्रॉक्सी का उपयोग नहीं कर रहा हूं...

वीपीएन कई चीजों में से एक है जो नेटवर्क कॉन्फ़िगरेशन के साथ खिलवाड़ करता है। अधिक सामान्यतः, नेटवर्क कनेक्शन में कोई भी परिवर्तन हो सकता है (और इसमें कुछ चीजें शामिल हैं जिन्हें आप "नेटवर्किंग" के रूप में नहीं सोच सकते हैं):

• वीपीएन सक्षम / अक्षम
• वायर्ड लैन कनेक्ट/डिस्कनेक्ट
• वाईफाई सक्षम / अक्षम / क्षेत्र परिवर्तन (जैसे भवन के दूसरे क्षेत्र में लैपटॉप ले जाना)
• ब्लूटूथ डिवाइस कनेक्ट/डिस्कनेक्ट ( ब्लूटूथ पैन के कारण )
• यहां तक ​​कि यूएसबी डिवाइस कनेक्ट/डिस्कनेक्ट/चालू/बंद

वीपीएन मामला उल्लेखनीय है क्योंकि यह "स्प्लिट" विकल्प की पेशकश कर सकता है, जो इस कारण से डॉकर कनेक्शन को फ्लमॉक्स करने से बच सकता है। लेकिन स्प्लिट वीपीएन उन सभी अन्य चीजों को गड़बड़ाने से रोकने वाला नहीं है।

मैं पुराने जमाने की RJ45 केबल का उपयोग कर रहा हूँ...

मुझे समझ में नहीं आता कि डॉक-मशीन इन घटनाओं के प्रति संवेदनशील क्यों है।

मैंने आरजे 45 प्लग/अनप्लग, वाईफाई स्विचिंग की कोशिश की। मेरी तरफ से कोई मुद्दा नहीं है।

क्या कुछ प्रसंस्करण समय की आवश्यकता हो सकती है? मैं इसमें एक शेल फ़ंक्शन के साथ दौड़ता रहता हूं जो करता है:

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 आह, उस स्थिति में, हाँ, आपको निश्चित रूप से डेमॉन के शुरू होने और अनुरोधों को स्वीकार करने के लिए एक संक्षिप्त अंतराल की प्रतीक्षा करने की आवश्यकता है। यही कारण है कि प्रोविजनिंग के दौरान हमारे डेमॉन के पुनरारंभ होने के बीच मशीन के पास डॉकर की प्रतीक्षा करने के लिए कोड है। यकीनन, हमें इसकी जांच start पर भी करनी चाहिए।

यह मुद्दा बहुत लंबा है और इसमें बहुत सारे विषयांतर हैं। अगर किसी का सामना इसी तरह से होता रहता है, तो कृपया https://github.com/docker/machine/issues/new पर विस्तृत जानकारी सहित एक नया खोलें:

• आप किस ओएस पर हैं
• नेटवर्किंग कॉन्फ़िगरेशन में कुछ भी असामान्य (वीपीएन, प्रॉक्सी, एसएसएच कॉन्फ़िगरेशन सेटिंग्स, आदि),
• --debug ध्वज के साथ दुर्व्यवहार करने वाले आदेशों का आउटपुट
• वर्चुअलबॉक्स ~/.docker/machine/machines/name/name से लॉग करता है।

धन्यवाद!

• एन