Snap refresh fails

This situation is different from the other Snap refresh posts in the #snapd category.

It is not working, while most of the system has connectivity.

# snap refresh
error: cannot refresh: cannot refresh snap-declaration for "core": Get
       net/http: request canceled while waiting for connection (Client.Timeout exceeded while
       awaiting headers)

There is a Launchpad issue #1639981 which describes a similar situation.

The journal outputs merely the same message

# journalctl --no-pager -n 1 -u snapd
-- Logs begin at Tue 2018-05-22 16:58:55 CEST, end at Mon 2019-02-18 21:24:08 CET. --
Feb 18 21:17:18 pons snapd[846]: stateengine.go:102: state ensure error: cannot refresh snap-declaration for "core": Get net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

while the resource is accessible to other processes.

# curl -I ''
HTTP/1.1 200 OK
Server: gunicorn/19.7.1
Date: Mon, 18 Feb 2019 17:57:06 GMT
Content-Type: application/x.ubuntu.assertion
Content-Length: 986
Snap-Store-Version: 11
X-View-Name: snapdevicegw.webapi_assertions.assertions_find
X-VCS-Revision: 9cd1a3f
X-Request-Id: 7DD4D03ACB830A325C7F01BB5C6AF1F1106C537
Age: 75
X-Cache: HIT from juju-7794b8-prod-ols-snap-store-indep-1375
X-Cache-Lookup: HIT from juju-7794b8-prod-ols-snap-store-indep-1375:3128
Via: 1.1 juju-7794b8-prod-ols-snap-store-indep-1375 (squid/3.5.27)

# curl ''
type: snap-declaration
authority-id: canonical
series: 16
snap-id: 99T7MUlRhtI3U0QFgl5mXXESAiSwt776
publisher-id: canonical
snap-name: core
timestamp: 2016-09-28T17:33:53.740774Z
sign-key-sha3-384: BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul


I also had to run

# ausearch -c 'snapd' --raw | audit2allow -M my-snapd
******************** WICHTIG ***********************
To make this policy package active, execute:

semodule -i my-snapd.pp

# semodule -X 300 -i my-snapd.pp

several times before snapd would be initially working with SELinux enabled.

How would one debug this kind of connectivity issue further?

This is a

# snap version
snap    2.37.2-1.fc29
snapd   2.37.2-1.fc29
series  16
fedora  29
kernel  4.20.8-200.fc29.x86_64

system, and no proxy is in place.

It uses a manually configured /etc/nsswitch.conf (circumventing authselect) setting it to use resolve before dns, and having /etc/resolv.conf symlinked to /lib/systemd/resolv.conf for NetworkManager, making it recognise the systemd-resolved stub resolver on

This was introduced in setting up update-systemd-resolved scripts for OpenVPN.

Now my intuition suggests me that this has to do with how Go binaries resolve DNS, by either mobilising Go or Cgo, indirectly via /etc/resolv.conf through the systemd-resolved stub resolver.

It’s been reported that the fast transition to systemd-resolved on Ubuntu and Fedora alike causes headaches for the maintainers of applications that rely on DNS resolution, like NetworkManager or OpenVPN. Is this maybe also the cause for snap stopping to work as expected, or are other forces at work here?

Does systemctl restart snapd help?

Just for the record, AFAIK Cgo is not disabled when snapd (the daemon) built on Fedora, so it should end up using whatever resolver and NSS setup glibc is configured with.

1 Like

systemctl restart snapd did not help, no.

My question would thus remain:

If resolver is really suspected, can you try and add the following to /etc/sysconfig/snapd:


This should force the use of Go resolver which IIRC only looks at /etc/resolv.conf.