Intermittent "permission denied" error when installing snaps

[Michael Terry]

I'm getting an odd occasional error when installing snaps that goes away if I immediately retry:

ubuntu@localhost:~$ sudo snappy install test_0_amd64.snap
2015/04/14 21:39:57 Signature check failed, but installing anyway as requested
open /apps/test/0/debs/usr/lib/i386-linux-gnu/libicudata.so.52: permission denied
unpack test_0_amd64.snap to /apps/test/0 failed with exit status 1

But if I retry again:

ubuntu@localhost:~$ sudo snappy install test_0_amd64.snap
Installing test_0_amd64.snap
<snip output of snappy list after successful install>

current build number: 381
device name: generic_amd64
channel: ubuntu-core/devel-proposed
last update: 2015-04-13 16:07:03
version version: 381
version ubuntu: 20150413.2
version raw-device: 20150413.2

[Michael Vogt (mvo)]

Could you make your test snap available so that we can reproduces this error please?

[Michael Terry (mterry)]

It doesn't seem to be specific to any one snap. I get it for various snaps. Next time it happens, I'll make that snap available.

[Michael Terry (mterry)]

Here's a snap that reproduced this three times for me before succeeding on the fourth attempt (sorry for 800M size):
https://chinstrap.canonical.com/~mterry/clockit_0_amd64.snap

Specifically, I saw the following errors before it succeeded:
Run 1: open /apps/clockit.sideload/0/debs/lib/x86_64-linux-gnu/libcgmanager.so.0: permission denied
Run 2: open /apps/clockit.sideload/0/debs/usr/share/doc/qtubuntu-desktop/copyright: permission denied
Run 3: open /apps/clockit.sideload/0/debs/usr/lib/x86_64-linux-gnu/dri/r300_dri.so: permission denied

[Michael Terry (mterry)]

So this error is coming from helpers/helpers.go in the UnpackTar/TarIterate function. I've seen both the os.OpenFile and os.Mkdir calls fail.

I put some testing prints in, and the os.MkdirAll right beforehand is succeeding, creating a directory that is writable by the clickpkg user. So I'm not sure why permission would be denied to create a file.

I looked at the definitions of os.Mkdir and os.OpenFile, but they are both just very thin wrappers around the underlying syscalls, so nothing suspicious to me there.

Digging more.

[Michael Terry (mterry)]

I think I found it. A goroutine/thread issue. See attached branch.