why am I receiving error starting microclimate on macos stating TLS handshake timeout - microclimate

I've successfully completed the ./install.sh command. When I run the next "~/mcdev start -o" I receive this error: "Starting Microclimate
Pulling microclimate-file-watcher (ibmcom/microclimate-file-watcher:1809)...
ERROR: Get https://registry-1.docker.io/v2/ibmcom/microclimate-file-watcher/manifests/1809: net/http: TLS handshake timeout
Error starting Microclimate"
I have running on my pc:
git version 2.17.1 (Apple Git-112); Docker version 18.06.1-ce; MacOS
High Sierra v 10.13.6; latest Microclimate v18.09
My network is up and I don't have any proxy.
What am I missing or doing wrong?

I got this to work by changing to a different wifi \ internet connection. Still not sure why my home wifi, with no restrictions that I'm aware of, will 'block' the dependency downloads upon start of Microclimate.
If anybody has additional info to help find the root cause please feel free to share.

This docker error generally shows up when your internet connection is too slow for Docker, as it times out performing the TLS handshake. This would also explain why moving to another network fixes the issue.

Related

Pytorch Install

I HAVE A ERROR IN INSTALLING PYTORCH:
PLEASE HELP ME.
CondaHTTPError: HTT P000 CONNECTION FAILED for url https://conda.anaconda.org/pytorch/win-64/current_repodata.json
Elapsed: -
An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.
'https//conda.anaconda.org/pytorch/win-64'
An HTTP error occurred when trying to retrieve this URL. HTTP errors are often intermittent, and a simple retry will get you on your way
The possible reason for HTTP error could be an unstable network connection or a corporate firewall.
If it was an unstable network connection, as mentioned in the Error message, retry the installation steps that failed.
If you are behind a corporate firewall, you might need additional steps to add your proxy server to the .condarc file on your machine.
Since you are on Windows, you could open the Anaconda prompt and run conda info to figure out where the .condarc file is located.
Find the proxy by running echo "$http_proxy" in your prompt. Copy the proxy.
Open the .condarc file and paste the proxy under proxy_servers section
For more details see: Anaconda Docs: Configure conda for use behind a proxy server (proxy_servers)

JFrog Artifactory OSS: UI service unavailable, "Trying to connect an http1.x server"

I'm trying to set up a new JFrog Artifactoy OSS server on a Windows 10 machine.
While it actually seems to be up and running the UI is not working. When trying to open http://localhost:8082/ui/ I just get a "Service unavailable" error.
In the /var/log/frontend-service.log I see the following error:
[main ] - Couldn't register on Router, retry number: 120, Error : [Trying to connect an http1.x server]
I couldn't find any errors in the other logs.
I already made some desperate attempts in my system.yaml like setting the IP manually, tested setting a proxy, etc. But no luck. Any ideas what might be going on here?
I also had the same problem, I solved it by exposing port 8082 as well:
docker run --name artifactory -d -p 8081:8081 -p 8082:8082 docker.bintray.io/jfrog/artifactory-oss:latest
I had this issue with version 7.7.3 and I just reverted to an older version I had 7.5.7 and it worked fine for me.

gnutls_handshake() failed: Close notify - Docker and Only on one network

Just came across a really odd problem.
I have been doing some work with Docker images and Dockerfile which included some bower install commands. It was all fine until today was the day I got a new broadband provider (Virgin Media in the UK) and all of a sudden i start getting errors whist trying to build images such as
bower ember#1.13.12 ECMDERR Failed to execute "git ls-remote --tags --heads https://github.com/components/ember.git", exit code of #128 fatal: unable to access 'https://github.com/components/ember.git/': gnutls_handshake() failed: Close notify
Additional error details:
fatal: unable to access 'https://github.com/components/ember.git/': gnutls_handshake() failed: Close notify
I then tried by tethering to my mobile phone (4g) and it works perfectly fine. So there are many commands in the bower.json and it seems to randomly fail at any.
Even a simple command like cloning a repo from within the Dockerfile , fails when i connect to my new network but works with other networks.
Oddly enough if i use the git clone command on my Mac or even the bower install with the exact same repo it all works fine (with new network and 4G) however as soon as I try to run via Dockerfile I get the errors.
I have checked my router and cannot really see if it is a router issue what it could possibly be. The WIFI signal is 200Mbs so it surely can't be that.
The error is raised because of the protocal used by git. Just replace 'https' with 'http', it works for my case.

Failed to connect before deadline

When I run query.js (similar to query.js in fabcar but modified for my application), I keep getting an error which says,
Failed to connect before the deadline
I have changed the localhost to docker IP address in enrollAdmin.js and registerUser.js
TLS is enabled for peer, orderer and cli.
Any help would be appreciated. Thanks
I had the exact same problem. These steps fixed it for me:
Open VirtualBox Manager and select the “default” VM
Click “Settings”, “Network”, “Advanced”, “Port Forwarding”.
Create a new rule by clicking the “+” sign on the right and entering the following: Name -> “grpc”, Host Port -> 7051, Guest Port -> 7051
You can leave the Host IP and Guest IP unspecified.
Thx to: https://developer.ibm.com/opentech/2017/11/29/running-hyperledger-fabric-windows-revised/
I had the same problem:
I think grpc and fabric-client package has issues or different versions than we need (verify the package.json for npm) . Therefore I decided to manually install the latest versions of the npm fabric-ca-client, fabric-client and grpc packages and it worked!!!!
I hope this solution works for you!!
I had the same issue as well
What works for me is that I reinstall the global window-build-tools and global grpc, and it works afterwards. Hope it helps!
What worked for me was changing the localhost to Docker's IP(seen when the docker terminal starts) in the network connections file(either connections.json or networkConnections.yaml) being used in the query.js(or any other js).

Cygwin Error : tcp_peer_send_blocking: send() to socket

My Cygwin installed on Windows 7 was working properly till I try to install a new package. The package installation failed. Then I keep getting this error every time I want to run my Open MPI program. I can successfully compile the program but cannot run it. I even remove and make a new installation without success.
Thanks for any hints. Below is the sample error message.
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
The problem is solved by disabling the unused network adapter in "Control Panel->Network and Internet->Network Connections".
It turned out the unused network adapter tried to get configured by DHCP and an IP address started with "169.254.X.X" was assigned to this adapter when DHCP fails. Somehow openmpi on Cygwin use that invalid IP address for establishing communication between processes.
I figured it out by looking at /tmp/openmpi-sessions-{username}/{PID of orterun}/contact.txt.
I had this same problem on Cygwin with OpenMPI 1.10.4.
Try adding "-report-uri -" to your mpirun command to see what IP address it's trying to use for connection:
mpirun -report-uri - -np 2 a.exe
It should print out a line that looks something like this:
568328192.0;tcp://192.168.10.103,169.254.247.11,0.0.0.0,0.0.0.0,0.0.0.0:55600
If the first IP address after the "tcp://" is not a current valid address for your machine, that's the problem and things are likely to break (even if the correct IP appears later in the list). Apparently ORTE is not smart enough to order the interfaces based on what is actually enabled and online.
If the wrong IP corresponds to an old/disabled interface, uninstall it (if possible) using the windows network connections control panel.
In my case, the first address was a DHCP address for an old hardware adapter I'd removed and thrown away long ago (but apparently not uninstalled in software). Windows normally hides such removed-but-not-uninstalled interfaces in the control panel, but the settings remain in the registry under:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\
Search in that registry subkey for the bogus IP address and you are likely to find the problematic interface. I fixed mine by changing the IP address in that registry key to match my current static IP, but uninstalling the interface entirely would probably also work.
I had the same problem with openmpi v 1.8.8 (which is the default version of the package installed by cygwin). Manually going back to version 1.8.6 fixed the issue for me.
I just encountered this problem and in my case I had to disable the "VirtualBox Host-Only Network" adapter (I recently installed virtualbox and have not used openmpi in cygwin after that until today).
1. Open the Cygwin terminal.
mpicc --version
mpirun --version
If not execute, follow the document below and reinstall everything. Document
2. Try turning off Bluetooth and test your program again.
3. Try closing the Wifi and test your program again (you can connect to the wired internete)
4. Open C:\Windows\System32\drivers\etc\hosts
add line
127.0.0.1 localhost cygdrive wpad
and test your program again.
5. If you have a virtual network like VirtualBox or similar, turn off the control panel and test your program again.
6. If possible, uninstall VirtualBox completely. Restart your computer and test your program again.
7. Try turning off the Windows Firewall and test your program again.
The above steps solved both the "tcp_peer_send_blocking: send () to socket 12 failed: transport endpoint is not connected" error and the slowness problem in MPI for Windows 10 - Cygwin.

Resources