Machine: معلقة عامل ميناء- آلة ENV xxx إلى الأبد

لدي مشكلة مماثلة مع نظام التشغيل windows 7. هنا جوهر ملف السجل.

ألاحظ أن "اسم آلة docker-machine env" يتعطل كثيرًا أيضًا ، خاصةً عندما يكون في ملفي الشخصي ~ /. ، يتسبب في توقف المحطات الطرفية الجديدة وعدم بدء تشغيلها بنسبة 50٪ تقريبًا. حاليًا فقط ctrl + c'ing على غلاف علامة التبويب الجديدة ، وتوليد واحدة أخرى بعد ثانيتين يميل إلى القيام بالمهمة.

من الصعب التكاثر في محطة جديدة / نشطة ، تميل إلى أن تكون أكثر في كثير من الأحيان عند وضع واحدة جديدة.

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 لبرنامج التشغيل virtualbox. تحدث المشكلة عادةً عندما يكون المسار إلى الشبكة الخاصة مفقودًا (الذي يستخدمه docker cli).
في حالتي ، أحد الأسباب التي تجعلني أشك في أن هذا المسار مفقود لأنني أستخدم شبكة ظاهرية خاصة تميل إلى العبث بمسارات الشبكة الخاصة. إصلاح هذا هو تشغيل شيء ما على طول:

sudo route add -net 192.168.99.0/24 -interface vboxnet6

حيث 192.168.99.0/24 هو نطاق الشبكة المستخدم بواسطة boot2docker و vboxnet6 الواجهة المخصصة لشبكة boot2docker الخاصة.

لقد جربت حل chantra لكنني لم أفعل الحيلة ، لا يزال docker-machine معلقًا عند استخدامه في غلاف جديد مع أي أمر فرعي. بالرغم من ذلك ، فإن المقاطعة مع ^C والمحاولة مرة أخرى تعمل.

مرحبًا بالجميع ، أي شخص يواجه هذه المشكلة ، فإن إحدى المشكلات المحتملة في اللعب هي أن Docker daemon لا يعمل.

هل يمكنك من فضلك محاولة / لصق إخراج الأوامر التالية (هذا مخصص لأجهزة VM التي تقوم بتشغيل 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 Hm ، يجب أن يعمل إلى حد كبير على الفور إذا كان سينجح ، لذلك إذا فهناك خطأ ما.

انتهى لتوه من:

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

تضمين التغريدة هل لديك شبكة افتراضية خاصة أو أي إعداد غير عادي فيما يتعلق بشبكتك ويمكن أن تفكر فيه؟

لا ، ليس هذا ما يمكنني التفكير فيه. قبل بضعة أيام كنت لا أزال أستخدم 0.1.0 وعملت بشكل مثالي ، ثم تم التحديث إلى 0.3.0 وبدأت في العمل بشكل غير تقليدي كما هو الحال حاليًا. لدي زميل عمل آخر ، fsaravia ، يعاني من نفس المشكلة.

nathanleclaire بعد التحدث مع زميلي وجدت أنني كنت أستخدم الإصدار التالي ، 'لأن الشخص الموجود في البيرة كان يعطيني هذا الخطأ:

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

إنه يستخدم أحدث إصدار ، لذلك حذفت هذا الإصدار ، brew install docker-machine ويبدو الآن أنه يعمل: smile_cat: آسف على المشكلة.

inkel نيس ، سعيد لأنك عملت.

لقد حاولت مرة أخرى باستخدام أحدث إصدار من آلة الرصيف ولكن دون جدوى. أنا أركض على windows 7 مع git shell. جميع الخطوات والمخرجات ذات الصلة هنا .

يحتوي ملف 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 الخروج من

بدأ جهاز vm وكانت خدمة عامل الميناء تخرب.
يمكنني 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 VMs. لقد أضفت للتو Docker Swarm وتفاقمت المشكلة عدة مرات (أكثر تكرارًا). لقد قضيت ساعتين أحاول صنع ثلاث آلات سرب. إذا قمت بإعادة التشغيل ، فعادة ما يتم إصلاحه ، لكن هذا ليس معقولاً. باستخدام docker-machine's --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 يعمل معي أيضًا. برنامج Cisco AnyConnect: الغضب:

أيضا Cisco AnyConnect. لا أفترض أنه يمكنك إضافة فحص يوصي بإصلاح جدول التوجيه إذا تم تشويهه بواسطة برنامج مثل هذا؟ التشخيص محبط للغاية. كنت لا أزال قادرًا على الدخول إلى آلة الرصيف ، التي تم تمهيدها بنجاح ، واضطررت إلى إلقاء نظرة على العديد من التذاكر قبل أن أجد المناقشة في هذا.

لا أفترض أنه يمكنك إضافة فحص يوصي بإصلاح جدول التوجيه إذا تم تشويهه بواسطة برنامج مثل هذا؟

هذا في الواقع هو الحل الدقيق الذي أفكر فيه الآن. في كثير من الحالات ، يبدو أنه يمكننا بالفعل إنهاء إنشاء المثيل بنجاح والحصول على عنوان IP ، ويصادف أنه لا يمكن الوصول إليه.

لدي أيضًا مشكلة عامل الرصيف الذي لا يمكن الوصول إليه بعد النوم .

كيف ستفعل حل chantra في Windows 10؟

لقد عانيت من هذه المشكلة أيضًا بعد عدة مرات نوم.
إعادة تشغيل حل المشكلة ..

حدث هذا لي أيضًا عندما يكون لديّ جهاز عامل إرساء يعمل ثم أشترك على 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 ، تراجع
• الافتراضي عامل عامل الميناء- آلة env فقط معلقة

حاولت إعادة تشغيل عامل الإرساء الافتراضي ، استمرت المشكلة.

يبدو أن حل chantra يعمل بالنسبة لي. على جهازي ، كانت الواجهة vboxnet0 (وجدت باستخدام ifconfig من محطة mac) بطريقة أسهل من إعادة التشغيل في كل مرة أحتاج فيها إلى استخدام VPN.

لست متأكدًا من أنني علقت على VPN الذي كنت أستخدمه ، لكن FWIW ، أنا أيضًا أستخدم cisco
أي اتصال ....

يوم الأربعاء ، 23 سبتمبر 2015 الساعة 7:52 مساءً ، جو مكجلين إخطارات @github.com
كتب:

أواجه هذه المشكلة أيضًا على نظام التشغيل Mac OS 10.10.4 مع Cisco AnyConnect
VPN.

• التمهيد الجديد ، عامل الميناء يعمل بشكل جيد
• اذهب إلى VPN ، تراجع
• الافتراضي عامل عامل الميناء- آلة env فقط معلقة

حاولت إعادة تشغيل عامل الإرساء الافتراضي ، استمرت المشكلة.

يبدو أن حل chantra https://github.com/chantra يعمل بالنسبة لي. تشغيل
جهازي كانت الواجهة vboxnet0 (وجدت باستخدام ifconfig من mac
Terminal) أسهل بكثير من إعادة التشغيل في كل مرة أحتاج فيها إلى استخدام VPN.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/machine/issues/1500#issuecomment -142788894.

FWIW كنت أستخدم أيضًا Cisco AnyConnect VPN ، على OS X 10.10.5 لقد جربت للتو فتح الاتصال بدلاً من ذلك ويبدو أنه تجنب المشكلة.

ronen ، شكرًا على النصيحة حول openconnect ، لم أكن أعلم أبدًا بوجودها. GoodBye AnyConnect: ابتسامة عريضة:

ChrisRut نعم لقد تعلمت للتو عن openconnect عند محاولة حل هذه المشكلة. GoodBye 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 في هذا الجوهر .

الغريب في الأمر أنه يتم تفريغ المخرجات الصحيحة بعد الوصول إلى الحد الأقصى لعدد المحاولات ، انظر نهاية السجل.

هذا هو خرج 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 التي يبدو أنها تسبب هذه المشكلة.

يبدو لي أنه من المحتمل أن تقوم _any_ VPN بفعل ذلك ، نظرًا لأن لديهم جميعًا نفس التعريف الأساسي لتجاوز التوجيه "العادي".

تحديث: باستخدام "اتصال مقسم" (خيار يسمح به التثبيت الخاص بي. عن طريق الاتصال بخادم VPN مختلف) ، يبدو أنني أتجنب ذلك.

انتظر ماذا؟ أنا لا أستخدم أي نوع من أنواع VPN أو البروكسي ...

VPN هي مجرد واحدة من العديد من الأشياء التي تعبث بتكوين الشبكة. بشكل عام ، قد يؤدي أي تغيير في اتصالات الشبكة (ويتضمن ذلك بعض الأشياء التي قد لا تفكر فيها على أنها "شبكة"):

• تمكين / تعطيل VPN
• اتصال LAN سلكي / فصل
• تمكين / تعطيل / تغيير المنطقة من WiFi (مثل حمل جهاز كمبيوتر محمول إلى منطقة أخرى من المبنى)
• اتصال / قطع اتصال جهاز Bluetooth (بسبب Bluetooth PAN )
• حتى جهاز USB توصيل / فصل / تشغيل / إيقاف

حالة VPN جديرة بالملاحظة لأنها قد توفر خيار "الانقسام" ، والذي قد يتجنب إرباك اتصال Docker من هذا السبب. لكن تقسيم VPN لن يمنع كل هذه الأشياء الأخرى من إفساد الأمور.

أنا أستخدم كابل RJ45 قديم الطراز ...

لا أفهم لماذا تعتبر آلة الرصيف حساسة لهذه الأحداث.

حاولت rj45 plug / unplug ، تبديل wifi. لا مشكلة من جانبي.

هل يمكن أن تكون هناك حاجة لبعض وقت المعالجة؟ أستمر في التعامل مع هذا مع وظيفة shell التي تقوم بما يلي:

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 Ah ، في هذه الحالة ، نعم ، أنت بالتأكيد بحاجة إلى الانتظار لفترة وجيزة لبدء البرنامج الخفي والبدء في قبول الطلبات. هذا هو السبب في أن الجهاز لديه رمز لانتظار Docker بين إعادة تشغيل البرنامج الخفي أثناء التزويد. يمكن القول ، يجب علينا التحقق من ذلك على start أيضًا.

هذه القضية طويلة جدًا وتحتوي على الكثير من الاستطراد. إذا استمر شخص ما في مواجهة أشخاص مشابهين ، فيرجى فتح واحدة جديدة على https://github.com/docker/machine/issues/new مع معلومات مفصلة بما في ذلك:

• ما هو نظام التشغيل الذي تستخدمه
• أي شيء غير نمطي في تكوين الشبكات (VPN ، الوكيل ، إعدادات تكوين SSH ، إلخ) ،
• إخراج أوامر سوء التصرف بعلامة --debug
• سجلات VirtualBox من ~/.docker/machine/machines/name/name .

شكرا!

• ن