Snapd: "cannot run daemon: cannot read state: unexpected EOF"

I have a Raspbian system with snapd, where the snapd daemon is no longer running. E.g. I get the following

$ sudo snap refresh
error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused

In the snapd systemd log I see the following repeated over and over until the service fails:

systemd[1]: Starting Snappy daemon...
snapd[313]: AppArmor status: apparmor not enabled
snapd[313]: AppArmor status: apparmor not enabled
snapd[313]: cannot run daemon: cannot read state: unexpected EOF
systemd[1]: snapd.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: snapd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Snappy daemon.

(stripped date and hostname in the above)

Any idea how to troubleshoot the cannot read state: unexpected EOF message? I checked the part of the source code that triggers it but see no immediate pointers.

By the way, FWIW, there may be a case of SD card corruption due to a power outage. If there’s any way to clean the “state” that would be great.

Thanks in advance for any pointers!

This is almost certainly because your state.json file is corrupted/empty. Please do not upload that file as it can contain sensitive information, namely macaroons or other authorization keys. Can you confirm if the following things work (you can use jq from the archive for this purpose):

$ sudo ls -lah /var/lib/snapd/state.json
$ sudo cat /var/lib/snapd/state.json | jq keys

the jq command should show something like

[
  "changes",
  "data",
  "last-change-id",
  "last-lane-id",
  "last-task-id",
  "tasks"
]

for a valid state.json

Just delete the state.json file and snapd will re-create it but note that this may lead to unexpected state for the installed snaps, so your installed snaps may then show up as broken, etc. so you might be better off with apt remove --purge snapd and then re-install.

Thanks @ijohnson for the quick response!

Yes, that file had got truncated (probably due to a power outage while it was being updated), and thus contained invalid JSON. It had got truncated near the end, at the last-change-id key (or last-cha, as it had become), so I just deleted the key fragment, restored to valid JSON, and things are looking fine again! I can also see that the few truncated fields have been repopulated.

Starting from scratch (or risking a truly “confused” system) would have been less desirable, since this is a system in rural Sierra Leone, and the actual tunnel that I’m using to connect to the device is itself managed by a snap.

Thanks again for helping out!

1 Like