/var/cache/snapd/commands.db: permission denied

I just installed the classic snap on my raspberry pi, and tried to run a git command before installing it. Rather than saying “no such command” or “hey, you probably want to install git,” it died with an error:

(classic)kyrofa@localhost:~/snapcraft$ git status
gadvise-command error: open /var/cache/snapd/commands.db: permission denied

What happened here? Some more info:

$ snap version
snap    2.31.2
snapd   2.31.2
series  16
kernel  4.4.0-1030-raspi2

$ snap list
Name        Version       Rev   Developer  Notes
classic     16.04         26    canonical  devmode
core        16-2.31.2     4209  canonical  core
pi2         16.04-0.17    29    canonical  gadget
pi2-kernel  4.4.0-1030-3  22    canonical  kernel
2 Likes

Thanks for this error report. I tried to reproduce it (in a VM though) and I could not reproduce the error (same snapd and classic versions).

What is the output of: ls -l /var/cache/snapd/commands.db when you are inside classic? Anything special installed inside classic? Or anything else that might be unusual that might help us to reproduce the issue?

Both outside classic and in:

kyrofa@localhost:~$ ls -l /var/cache/snapd/commands.db
-rw-r--r-- 1 root root 262144 Mar 21 14:57 /var/cache/snapd/commands.db
kyrofa@localhost:~$ sudo classic
(classic)kyrofa@localhost:~$ ls -l /var/cache/snapd/commands.db
ls: cannot access '/var/cache/snapd/commands.db': No such file or directory

Nothing unusual about this image, just the normal rpi2 image. Note that I removed the classic snap and reinstalled it, so it was pretty clean when this happened.

my guess is that whoever added this file to core did not update livecd-rootfs to actually include it in the classic tarball we generate at core build time …

Well, and that tarball isn’t actually unpacked again to update the chroot created when sudo classic is initially run anyway, is it?

nope, you would have to do:

sudo classic.reset
sudo classic

to have the chroot re-created (my point is that the tarball we include inside the core squashfs simply doesnt include that file, the classic snap doesnt ship any of the chroot content so someone would need to fix the core build scripts)

Just wanted to confirm I recently came across the same issue. Slightly different scenario, but 100% in line with the potential root cause diagnosed here.

Namely, a custom raspberry pi image that does not include the classic snap, but where the snap is installed after first boot. Again, the /var/cache/snapd/commands.db file was shown as missing when in the classic chroot.

I haven’t tried @ogra’s classic.reset suggestion yet but will do when I get the chance.

Here is the (rather obvious) workaround:

(classic)ogra@someboard:~$ git status
advise for command failed: write /var/cache/snapd/commands.db: bad file descriptor
(classic)ogra@someboard:~$ logout
ogra@someboard:~$ sudo cp /var/cache/snapd/commands.db /var/snap/classic/common/classic/var/cache/snapd/
ogra@someboard:~$ sudo classic
(classic)ogra@someboard:~$ git status
git: command not found
(classic)ogra@someboard:~$

https://github.com/snapcore/classic-snap/pull/16

Thanks for this error report. This should be fixed in the current “beta” core.

1 Like