Failed to update: gnutls_handshake() failed
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Snappy |
High
|
Unassigned | ||
Bug Description
During the jenkins executions of the integration tests I found this error:
sudo snappy update
error from system-image-cli: gnutls_handshake() failed: The TLS connection was non-properly terminated.: https:/
/tmp/snappy-
...open /tmp/snappy-
/tmp/snappy-
...open /tmp/snappy-
... value *exec.ExitError = &exec.ExitError
... Error: error from system-image-cli: gnutls_handshake() failed: The TLS connection was non-properly terminated.: https:/
| Changed in snappy: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| Michael Vogt (mvo) wrote : | #1 |
| Leo Arias (elopio) wrote : | #2 |
I ran the loop many times from the jenkins machine. No errors there either.
| Leo Arias (elopio) wrote : | #3 |
I've send an RT. Will keep you posted.
| Federico Gimenez (fgimenez) wrote : | #4 |
This error is showing up again frequently in the jenkins executions [1], [2]
[1] http://
[2] http://
| Leo Arias (elopio) wrote : | #5 |
this morning it failed on ubuntu-device-flash like this: http://
| Leo Arias (elopio) wrote : | #6 |
another u-d-f error today: http://
| Leo Arias (elopio) wrote : | #7 |
As suggested by nessita, I'm opening different bugs for the package download and the icon download, because they are in different servers: bug #1510136 and bug #1510138. We can keep this one to track the failure to download from system-image.
| Leo Arias (elopio) wrote : | #8 |
Even if this happens to be a problem in the servers, the client should handle this better with retries.
| Leo Arias (elopio) wrote : | #9 |
we are no longer using system image. We already have bugs opened for downloads failing on the store, so I'm just closing this.
| Changed in snappy: | |
| status: | Triaged → Invalid |


This error comes from the "system-image-cli" binary which uses pycurl/gnutls. This means that either the system-image server or the client have problems, its odd that it only happens sometimes (or a network problem with the datacenter which seems unlikely).
Do you see any pattern when it comes to the architecture or anything else? Or is it just random?
Fwiw, it seems like its happening in gnutls deep in gnutls_ record. c:recv_ headers( ) its also not a timeout issue as this will trigger a different error code in gnutls.
Whats strange is that /system- image.ubuntu. com/gpg/ image-master. tar.xz >/dev/null; sleep 0.2; done
"""
for i in $(seq 10); do curl https:/
"""
does work just fine for me. I wonder if we could run this on the jenkins host to see if that shows errors there.