Problem with content interface and parallel install

Hi,
i am currently working on a snap that makes use of parallel install. The snap also uses a content interface (“spool mode”?, inverse direction). It seems like the content interface is not resolving the path correctly.

slots:
  package-assets:
    interface: content
    content: package-assets
    source:
      read:
      - $SNAP_DATA/package-assets/${SNAPCRAFT_PROJECT_NAME}

The mount is pointing to /var/snap/my-snap/current/package-assets/my-snap instead of /var/snap/my-snap_key/current/package-assets/my-snap

This seems somehow similar / releated to Layout issues in aws-iot-greengrass with parallel instances but the 2.49 did not fix it in this case.

IIRC this is correct. /var/snap/my-snap_key is set up to be a bind mount on /var/snap/my-snap. For most applications, even if you hardcoded in /var/snap/my-snap before in your program, running as a parallel installed instance should be completely transparent. See the section about Snap environment, data and namespace in https://snapcraft.io/docs/parallel-installs. Those changes are made before any content mounts are applied.

If you believe that the content is showing up incorrectly, please attac the contents of /var/lib/snapd/mount/snap.<yoursnap>.<yourapp>.fstab, then execute the commands below and attach the output:

$ snap run --shell <snap>.<app>
# inside the snap shell
$ findmnt

Hi,

I still do believe the content shows up incorrectly. Find the requested information below.

findmnt did not work, does it need devmode?

snap list
[...]
snapd                   2.49                      11107  latest/beta    canonical✓  snapd
octoprint-sdev_artistd  1.5.3-devel+202102142159  x1     -              -           -
octoprint-sdev_mega     1.5.3-devel+202102142159  x1     -              -           -
[...]

# I created a file wrongdir from outside the snap, just to add clearity
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# ls
wrong_dir
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# snap run --shell octoprint-sdev_mega
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# cd $SNAP_DATA
root@idefix:/var/snap/octoprint-sdev/x1# cd package-assets/octoprint-sdev/
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# ls
octoprint-sdev_mega.package-manifest.json
# Seems like from within the snap shell everything looks correctly

# Now on the counter part
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# snap run --shell rexroth-deviceadmin.web
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# cd $SNAP_DATA
root@idefix:/var/snap/rexroth-deviceadmin/x2# cd package-assets/octoprint-sdev/
root@idefix:/var/snap/rexroth-deviceadmin/x2/package-assets/octoprint-sdev# ls
wrong_dir
# Wrong dir is mounted on the counter part

# Output of *.fstab
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# cat /var/lib/snapd/mount/snap.octoprint-sdev_mega.fstab 
/snap/octoprint-sdev_mega /snap/octoprint-sdev none rbind,x-snapd.origin=overname 0 0
/var/snap/octoprint-sdev_mega /var/snap/octoprint-sdev none rbind,x-snapd.origin=overname 0 0
/var/snap/octoprint-sdev/x1/dist-packages /snap/octoprint-sdev/x1/usr/lib/python3/dist-packages none rbind,rw,x-snapd.origin=layout 0 0
/var/snap/octoprint-sdev/x1/site-packages /snap/octoprint-sdev/x1/usr/lib/python3/site-packages none rbind,rw,x-snapd.origin=layout 0 0
/var/snap/octoprint-sdev/x1/dist-packages /snap/octoprint-sdev/x1/usr/local/lib/python3/dist-packages none rbind,rw,x-snapd.origin=layout 0 0

root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# cat /var/lib/snapd/mount/snap.rexroth-deviceadmin.fstab
/snap/rexroth-deviceadmin/x2/shadow /etc/shadow none bind,rw,x-snapd.kind=file,x-snapd.origin=layout 0 0
/snap/rexroth-automationcore/x1/package-assets/rexroth-automationcore /var/snap/rexroth-deviceadmin/x2/package-assets/rexroth-automationcore none bind,ro 0 0
/snap/ctrlx-influxdb/x5/package-assets/ctrlx-influxdb /var/snap/rexroth-deviceadmin/x2/package-assets/ctrlx-influxdb none bind,ro 0 0
/snap/ctrlx-deconz/x79/package-assets/ctrlx-deconz /var/snap/rexroth-deviceadmin/x2/package-assets/ctrlx-deconz none bind,ro 0 0
/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev /var/snap/rexroth-deviceadmin/x2/package-assets/octoprint-sdev none bind,ro 0 0
/var/lib/snapd/hostfs/var/lib/dhcp /var/lib/dhcp none bind,rw,x-snapd.ignore-missing 0 0
/var/snap/rexroth-automationcore/common/package-certificates/rexroth-automationcore /var/snap/rexroth-deviceadmin/common/package-certificates/rexroth-automationcore none bind 0 0

# findmnt not working
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# snap run --shell octoprint-sdev_mega.octoprint-sdev
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# findmnt
bash: /bin/findmnt: Permission denied

root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# snap run --shell rexroth-deviceadmin.web
root@idefix:/var/snap/octoprint-sdev/x1/package-assets/octoprint-sdev# findmnt
bash: /bin/findmnt: Permission denied

If you need further information, let me know.

Thanks.

I see now what you try to achieve. This is a slightly different use case as you are using the parallel instances of the snap providing the content slot. Can you provide the output of snap connections rexroth-deviceadmin ?

Sure. Here is the output

Interface                      Plug                                        Slot                                         Notes
[...]
content[package-assets]        rexroth-deviceadmin:package-assets          octoprint-sdev_mega:package-assets           manual
content[package-assets]        rexroth-deviceadmin:package-assets          rexroth-automationcore:package-assets        manual
content                        rexroth-deviceadmin:package-run             -                                            -
[...]

Unfortunately this use case is not supported at the moment. You can safely use a snap with an instance key on the plug side of the content interface connection, but using one on the slot side will produce confusing results, like ones you have observed. In fact, I think we should reject such connection of the content interface until there’s support in place. TBF, I’ve always considered using a parallel instance of a snap on the slot side to be confusing at best and something that should be avoided, supposedly with exception of content interfaces although it’s bit muddy since in theory you can mix content from different instances tracking different channels.

If you can, please file a bug report https://bugs.launchpad.net/snapd/. We have just released 2.49, but maybe we can land something in time for 2.50.

Thanks for your investigation. I will file a bug report on launchpad. For us it is essential to have the 1-plug to n-slots scenario since all snaps share information with the 1-snap on plug side, but the content should not be shared between the others. I have to say that I expected some problems using parallel installs with this scenario, but hopped there is an easy solution.

Thanks.

Edit: Bug on launchpad: https://bugs.launchpad.net/snapd/+bug/1915709

Hi @mborzecki,

Any update on this?

Thanks.