Make a snap writable temporarily for debugging

snapd
1

When debugging issues with MAAS, we often find ourselves modifying the source code of a running deployment. This is to add more debugging logging, since we can’t anticipate everything that we need log.

When MAAS in installed as a deb packages, it’s easy. Modify the code in place and restart MAAS.

When MAAS is installed as a snap it gets a bit trickier, since obviously you can’t simply modify the source code that’s in /snap/maas/current/.

It would would be nice if there was a way of telling snapd to make the snap writable temporarily. Then when you’re done debugging, you can tell snapd to make it read-only again, reverting back the code to the previous state.

I currently do this:

  1. sudo unsquashfs -d mutable-dir /var/lib/snapd/snaps/maas_5229.snap
  2. sudo snap try mutable-dir
  3. <make changes, debug, etc.>
  4. sudo snap refresh maas channel=2.7/edge --amend

It works, but I think the experience could be better. It has the following problems:

  1. There’s no guarantee that the maas_5229.snap actually is the snap that is currently running
  2. If someone else looks as snap list, there’s no indication of what’s going on, except that the revision is x1.
  3. When switching back to the pristine code and make it read-only again, you have to make sure that you choose the right channel.

For 3., snap revert maas kind of could be used, but you risk loosing data that was written by the app during the debugging session.

Is there any better way of doing what I want to do?

1 Like
2

snap try I think will be useful here. Eg:

$ snap download maas
$ unsquashfs ./maas_*.snap
$ sudo snap try ./squashfs-root

Now it is installed like a normal snap, but if you change files in ./squashfs-root, they are reflected in the system (snap try is using a bind mount under the hood rather than a squashfs mount).

3

I think that’s exactly what @bjornt is doing, no? :slight_smile:

But there may be an even simpler option if you already have the code locally - snapcraft try:

[EDIT]

There could be something that would improve this even more - the ability to parallel try. This way you could have the stable maas installed, and next to it, have a maas_dev. This way you wouldn’t need to refresh back’n’forth between the snap and the try. You could do the reverse today by using snap install maas_stable and then snapcraft try'ing the development version.

4

Oh, duh, I apparently did not read @bjornt’s full question. d’oh! Sorry @bjornt!