Machine: docker-machine env xxx hang selamanya

Saya memiliki masalah serupa dengan OS windows 7. di sini adalah inti dari file log.

Saya perhatikan "docker-machine env machinename" juga sering hang, terutama ketika ada di ~/.profile saya, menyebabkan terminal baru hang dan tidak mulai 50% dari waktu sekitar. Saat ini cukup ctrl+c'ing shell tab baru, dan memunculkan satu lagi 2 detik kemudian cenderung melakukan pekerjaan itu.

Sulit bereproduksi di terminal baru/aktif, cenderung jauh lebih sering saat bertelur di terminal baru.

OSX 10.10.4, Mesin Docker 0.3.0. Masalah ini tidak ada di 0.2.x.

Saya memiliki masalah yang sama dengan status keluar yang aneh 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)"

Saya dapat mereproduksi masalah ini di MacOSX untuk driver virtualbox. Masalah biasanya terjadi ketika rute ke jaringan pribadi tidak ada (yang digunakan oleh docker cli).
Dalam kasus saya, salah satu alasan saya menduga rute ini hilang adalah karena saya menggunakan VPN yang cenderung mengacaukan rute jaringan priv. Perbaikan untuk ini adalah menjalankan sesuatu:

sudo route add -net 192.168.99.0/24 -interface vboxnet6

Di mana 192.168.99.0/24 adalah rentang jaringan yang digunakan oleh boot2docker dan vboxnet6 antarmuka yang ditetapkan ke jaringan pribadi boot2docker.

Saya sudah mencoba solusi @chantra tetapi tidak berhasil, docker-machine masih hang ketika di Shell baru dengan subperintah apa pun. Menginterupsi dengan ^C dan mencoba lagi berhasil.

Hai semua, siapa pun yang mengalami masalah ini, salah satu masalah yang mungkin terjadi adalah daemon Docker tidak berjalan.

Bisakah Anda mencoba/menempelkan output dari perintah berikut (ini untuk VM yang menjalankan boot2docker):

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

Terima kasih!

@nathanleclaire ketika saya mencoba menjalankan perintah itu, hang di sini:

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

Setelah jika selesai (jika pernah) saya akan menempelkan apa yang berikutnya.

@inkel Hm, itu harus segera berjalan jika itu akan berhasil, jadi jika butuh lebih dari beberapa detik ada yang salah.

Itu baru saja selesai dengan:

SSH cmd err, output: <nil>:

Butuh waktu lebih dari beberapa detik. Saya menjalankan lagi dengan time untuk melihat berapa banyak.

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

Jika Anda menjalankan:

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

dari CLI sendiri, apa yang Anda dapatkan?

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

Saya pikir saya telah membuat kesalahan dengan komentar saya sebelumnya, ini adalah output yang benar:

$ /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... setelah beberapa menit, berikut ini muncul di layar saya:

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 Aneh. Apakah Anda memiliki VPN atau pengaturan yang tidak biasa sejauh jaringan Anda berjalan yang dapat Anda pikirkan?

Tidak, bukan itu yang bisa saya pikirkan. Beberapa hari yang lalu saya masih menggunakan 0.1.0 dan bekerja dengan sempurna, kemudian diperbarui ke 0.3.0 dan mulai bekerja funky seperti saat ini. Saya punya rekan kerja lain, @fsaravia , yang menderita masalah yang sama.

@nathanleclaire setelah berbicara dengan kolega saya, saya menemukan bahwa saya menggunakan versi berikut, karena yang ada di homebrew memberi saya kesalahan ini:

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

Dia menggunakan yang terbaru, jadi saya menghapus versi itu, brew install docker-machine dan sekarang sepertinya berfungsi :smile_cat: sorry for the trouble.

@inkel Bagus, senang Anda berhasil.

Saya baru saja mencoba lagi dengan mesin buruh pelabuhan versi terbaru tanpa hasil. Saya menjalankan di windows 7 dengan git Shell. Semua langkah dan output masing-masing ada di sini .

File out.log berisi langkah-langkah utama. Lalu ada docker-machine-create.log dan docker-machine-env.log

Setelah secara manual mengatasi file sertifikat dari /var/lib/boot2docker/tls/ ke /c/Users/Pedro/.docker/machine/machines/test/

Saya mencoba lagi dan log yang dihasilkan adalah docker-machine-env-2.log
Bahkan dengan variabel lingkungan yang diekspor pada akhirnya saya masih tidak dapat terhubung.
docker ps keluar dengan kesalahan waktu habis

Vm memang mulai dan layanan buruh pelabuhan rusak.
Saya dapat ssh pada mesin dan layanan buruh pelabuhan mendengarkan pada port yang benar (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

Hal yang menarik adalah bahwa boot2docker bekerja dengan baik.
Ada pikiran lagi?
Terima kasih.

Masalah ini sangat sulit untuk direproduksi... Setelah menghapus semua vmboxnet_x kecuali vmboxnet0 dan vmboxnet1, dan me-reboot komputer (bukan mesin buruh pelabuhan), masalah saya hilang.

Setelah meletakkan komputer saya ke mode tidur beberapa kali dan kemudian mencoba lagi, saya mulai mengalami masalah yang sama. Ketika saya memiliki momen untuk memulai kembali sepenuhnya, saya akan mencoba lagi dan melihat apa yang terjadi.

Saya memiliki versi terbaru dari semua aplikasi Docker. Saya mendapatkan masalah dan mematikan selama berminggu-minggu dengan Docker Machine di Linux Ubuntu membangun VM VirtualBox. Saya baru saja menambahkan Docker Swarm dan masalahnya menjadi beberapa kali lebih buruk (lebih sering). Saya telah menghabiskan dua jam mencoba membuat tiga mesin swarm. Jika saya reboot biasanya memperbaikinya, tetapi itu tidak masuk akal. Menggunakan --debug docker-machine Anda dapat melihat di mana itu tergantung seperti yang ditunjukkan oleh komentator lain. Saya melihatnya menggantung di beberapa tempat dengan Daemon not responding yet: dial tcp 192.168.99.XXX:2376: no route to host , tetapi batas waktu selalu terjadi pada saat ini:

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 seperti apa konfigurasi ssh pengguna Anda? lihat: https://github.com/docker/machine/issues/1591

Solusi @chantra bekerja untuk saya. memang, penyebabnya adalah rute saya dihancurkan oleh perangkat lunak VPN

Saya baru saja mengalami ini juga, solusi @chantra bekerja untuk saya juga. Cisco AnyConnect :marah:

Juga Cisco AnyConnect. Saya kira Anda tidak dapat menambahkan tanda centang yang merekomendasikan untuk memperbaiki tabel perutean jika sudah rusak oleh perangkat lunak seperti ini? Sangat frustasi untuk mendiagnosis; Saya masih dapat ssh ke mesin buruh pelabuhan, yang berhasil di-boot, dan harus melihat banyak tiket sebelum saya menemukan diskusi dalam yang satu ini.

Saya kira Anda tidak dapat menambahkan tanda centang yang merekomendasikan untuk memperbaiki tabel perutean jika sudah rusak oleh perangkat lunak seperti ini?

Ini sebenarnya solusi tepat yang sedang saya pertimbangkan saat ini. Dalam banyak kasus, tampaknya kita benar-benar berhasil menyelesaikan pembuatan instance dan mendapatkan alamat IP, tetapi kebetulan tidak dapat dijangkau.

Saya juga memiliki masalah buruh pelabuhan yang tidak dapat dijangkau setelah tidur .

Bagaimana Anda melakukan solusi @chantra di Windows 10?

saya mengalami masalah ini juga setelah beberapa kali tidur.
restart memperbaiki masalah..

Ini terjadi pada saya juga ketika saya menjalankan mesin buruh pelabuhan dan kemudian saya menggunakan VPN, perintah hanya hang selamanya.
Namun, saya turun dari VPN melakukan restart mesin docker-machine restart <MACHINE-NAME> dan mulai bekerja lagi.

Ini terjadi pada saya juga ketika saya menjalankan mesin buruh pelabuhan dan kemudian saya menggunakan VPN, perintah hanya hang selamanya.
Namun, saya turun dari VPN melakukan restart mesin docker-machine restartdan itu mulai bekerja lagi.

Ini juga terjadi pada saya: Saya menjalankan mesin buruh pelabuhan, menggunakan VPN, keluar dari VPN, dan docker env <MACHINE-NAME> hang

Namun saya melakukan docker-machine restart <MACHINE-NAME> dan itu tidak membantu -- docker env <MACHINE-NAME> masih menggantung.

Saya juga mengalami masalah ini di Mac OS 10.10.4 dengan Cisco AnyConnect VPN.

• Boot baru, buruh pelabuhan berfungsi dengan baik
• buka VPN, mundur
• docker-machine env default baru saja hang

Mencoba me-restart mesin buruh pelabuhan, masalah tetap ada.

Solusi @chantra sepertinya berhasil untuk saya. Di mesin saya, antarmuka adalah vboxnet0 (ditemukan menggunakan ifconfig dari terminal mac) Jauh lebih mudah daripada me-reboot setiap kali saya harus menggunakan VPN.

Tidak yakin saya telah berkomentar VPN apa yang saya gunakan, tetapi FWIW, saya juga menggunakan cisco
ada koneksi....

Pada hari Rabu, 23 Sep 2015 jam 19.52, Joe McGlynn [email protected]
menulis:

Saya juga mengalami masalah ini di Mac OS 10.10.4 dengan Cisco AnyConnect
VPN.

• Boot baru, buruh pelabuhan berfungsi dengan baik
• buka VPN, mundur
• docker-machine env default baru saja hang

Mencoba me-restart mesin buruh pelabuhan, masalah tetap ada.

@chantra https://github.com/chantra 's solusi tampaknya bekerja untuk saya. Pada
mesin saya, antarmuka adalah vboxnet0 (ditemukan menggunakan ifconfig dari mac
terminal) Jauh lebih mudah daripada me-reboot setiap kali saya harus menggunakan VPN.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/machine/issues/1500#issuecomment -142788894.

FWIW Saya juga menggunakan Cisco AnyConnect VPN, di OS X 10.10.5 saya baru saja mencoba openconnect dan sepertinya menghindari masalah.

@ronen , Terima kasih atas tip tentang openconnect, saya tidak pernah tahu itu ada. Selamat tinggal AnyConnect :nyengir:

@ChrisRut ya saya baru belajar tentang openconnect ketika mencoba menyelesaikan masalah ini. Selamat tinggal AnyConnect memang! Saya menemukan openconnect agak rumit untuk digunakan, jadi saya mengumpulkan pembungkus cepat yang memungkinkan Anda mengetik "vpn up" dan "vpn down". Ada di https://Gist.github.com/ronen/7d486adbde5d6bfd2472 jika Anda tertarik

Karena tampaknya kami memiliki banyak masalah pada gejala yang sama, saya membuka #1934 untuk mereka yang mengalami masalah pada host Windows 10 (atau mungkin versi lain) setelah tidur. Untuk memisahkan masalah, saya sarankan untuk menghubungkan judul masalah ini dengan masalah jaringan VPN.

Saya mendapatkan masalah ini setelah mesin Host saya tertidur, dan saya kembali lagi nanti. Saya akhirnya menghapus semuanya dari folder c:usersdan.dockermachine saya (selain cache), lalu buat ulang semuanya. Lebih cepat melakukan itu daripada me-reboot mesin Host! ;)

Oh, dan saya juga harus mematikan beberapa proses sebelum melakukan itu. Saya cenderung memiliki 3 proses 'VBoxHeadless.exe', 3 'VBoxNetDHCP.exe', dan 'VirtualBox Interface'.

Saya membangunkan notebook saya dan menghapus instance mesin buruh pelabuhan dengan nama "dev".
Saya menjalankan perintah berikut untuk membuat dua mesin virtual baru:

$ 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 hang selama beberapa menit dan membuang yang berikut ke stderr:

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

Output log stdout dapat ditemukan di Gist ini.

Yang aneh adalah output yang benar dibuang setelah jumlah percobaan ulang maksimum tercapai, lihat akhir log.

Ini adalah keluaran stdout waktunya:

$ 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

Dan semakin asing...
Perintah yang sama untuk mesin virtual pertama dijalankan tanpa masalah:

$ 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 Jika Anda menambahkan garis miring ke *PROXY opsi misalnya --engine-env HTTP_PROXY=http://10.206.246.20:8080/ , apakah berhasil atau terus gagal?

Saya mendapatkan ini sekarang di Debian 8.2.

Tambahkan Jupiter Junos Pulse ke daftar perangkat lunak VPN yang tampaknya menyebabkan masalah ini.

Bagi saya kemungkinan besar _any_ VPN akan melakukan ini, karena mereka semua memiliki definisi dasar yang sama untuk mengesampingkan perutean "biasa".

Pembaruan: dengan menggunakan "koneksi terpisah" (opsi yang memungkinkan instalasi saya. dengan menghubungkan ke server VPN yang berbeda), sepertinya saya menghindari ini.

Tunggu apa? Saya tidak menggunakan VPN atau proxy apa pun...

VPN hanyalah salah satu dari banyak hal yang mengacaukan konfigurasi jaringan. Secara lebih umum, setiap perubahan dalam koneksi jaringan mungkin (dan itu mencakup beberapa hal yang mungkin tidak Anda anggap sebagai "jaringan"):

• Aktifkan/nonaktifkan VPN
• Sambungkan/putuskan sambungan LAN kabel
• WiFi mengaktifkan / menonaktifkan / mengubah zona (seperti membawa laptop ke area lain di gedung)
• Sambungkan/putuskan perangkat Bluetooth (karena Bluetooth PAN )
• bahkan perangkat USB menghubungkan/memutuskan/menghidupkan/mematikan

Kasing VPN patut diperhatikan karena mungkin menawarkan opsi "split", yang dapat menghindari kebingungan koneksi Docker dari penyebab ini. Tetapi VPN terpisah tidak akan mencegah semua hal lain itu mengacaukan segalanya.

Saya menggunakan kabel RJ45 kuno ...

Saya tidak mengerti mengapa mesin buruh pelabuhan begitu sensitif terhadap peristiwa ini.

Saya mencoba pasang/cabut rj45, beralih wifi. Tidak ada masalah di pihak saya.

Mungkinkah ada kebutuhan untuk beberapa waktu pemrosesan? Saya terus mengalami ini dengan fungsi Shell yang melakukan:

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

Ketika saya melakukan perintah ini satu per satu, dengan jari saya, itu berjalan dengan baik. Tetapi ketika dijalankan dari skrip, urutan perintah yang sama berfungsi sekali, daripada hang (atau membutuhkan beberapa menit).

Menghubungkan ke @mrumpf , VM ini adalah yang kedua dalam daftar docker-machine ls .

@jrep Ah, dalam hal ini, ya, Anda pasti perlu menunggu beberapa saat untuk daemon untuk memulai dan mulai menerima permintaan. Itu sebabnya Mesin memiliki kode untuk menunggu Docker di antara daemon kami restart selama penyediaan. Bisa dibilang, kita harus memeriksanya di start juga.

Masalah ini sangat panjang dan mengandung banyak penyimpangan. Jika seseorang terus menemukan yang serupa, silakan buka yang baru di https://github.com/docker/machine/issues/new dengan informasi terperinci termasuk:

• OS mana yang Anda gunakan
• Apa pun yang tidak biasa dalam konfigurasi jaringan (VPN, proxy, pengaturan konfigurasi SSH, dll.),
• Output dari perintah yang salah dengan flag --debug
• VirtualBox mencatat dari ~/.docker/machine/machines/name/name .

Terima kasih!

• n