snapd run from refresh-bits panics in InternalToolPath

[jhenstridge]

I was trying to use refresh-bits to test out a change to snapd, and had snapd panic with the following message:

2017/09/08 12:49:03 InternalToolPath can only be used from snapd, got: /home/james/src/.../snapd.amd64

This happened when I was trying to connect an interface that changed the mount configuration for the snap. The call in question seemed to come from interfaces/mount/ns.go, which doesn't seem to like the way refresh-bits builds snapd.

[zyga]

Based on a conversation just a moment ago this is a self-defense mechanism that has gone a bit to far. As for devtools, I haven't used them myself in a while so there are probably a whole lot of things gone stale. For smaller things that I usually work with I resort to make hack

[jhenstridge]

This is a bit of a hack, but the following seems to work to temporarily test out a new build of snapd without overwriting the distro packaged version:

go build ..../snapd
sudo systemctl stop snapd
sudo systemctl set-environment SNAP_REEXEC=0
sudo mount --bind $PWD/snapd /usr/lib/snapd/snapd
sudo systemctl start snapd

And to reverse the process:

sudo systemctl stop snapd
sudo umount /usr/lib/snapd/snapd
sudo systemctl unset-environment SNAP_REEXEC
sudo systemctl start snapd

[zyga]

I also stop the socket sudo systemctl stop snapd.{socket,service}

[datenhahn]

I used them successfully by setting the CMD_PREFIX to an empty string. I am using ubuntu-core inside a virtualbox vm for testing, so I am not afraid to rollback to a snapshot. But in general I didn't have problems with the automatic devtools rollback:

https://github.com/zyga/devtools/blob/02c3f0026823056b6519e8e593b893e12c242617/refresh-bits#L45

-CMD_PREFIX=devtools.
+CMD_PREFIX=""

The problematic line in the snapd is:

https://github.com/snapcore/snapd/blob/master/cmd/cmd.go#L128

If I interpret it correctly, it would be enough to rewrite the CMD_PREFIX as a "CMD_SUFFIX" (code has to be changed accordingly) with the value ".test".