With content-interface, normally, people need to connect relevant plug and launch the app afterwards.
For a dockerized-app, it will be
$snap connect docker-app:docker-executables docker:docker-executables
then
$sudo docker-app.redis-hello-world
And when an application is fired up, the context in which it is run will execute the bind mount so that the bind mount will not take place until the an app startup.
However according to my observation, when it comes to a daemon-based app,
…
redis-hello-world:
command: docker-wrapper docker-compose -f $SNAP/services/redis-hello-world/docker-compose.yml up
daemon: simple
plugs: [network, docker-executables, docker-cli]
due to the shared folder being not mounted while a daemon runs, it causes daemon fails to run if it relies on sth from producer end to work, even after a reload for docker-app upon the plug connection(Is this considered a bug?).
I took a look at ubuntu-app-platform snap and created a simple daemon-based snap to list the children of shared folders from ubuntu-app-platform for testing purpose. It works and turns that the platform slot is auto-connected upon the daemon snap installation and we don’t need to have a manual connection. So this time a daemon-based app works.
slots:
content:
allow-auto-connection:
-
plug-attributes:
content: $SLOT(content)
slot-attributes:
content: ubuntu-app-platform1
It look like an auto-connection interface on producer end is needed in this case so that a consumer snap can get relevant plug connected upon installation and we can have a daemon-baed app running. Do I have this correct?
Thanks.
This was a long-standing bug in snapd since the content interface was first introduced, but we’ve addressed that problem recently and snapd can currently take connections of those interfaces dynamically and update the mount namespaces of the snap in-place, without any processes restarting or any other change.
Hey, @zyga-snapd, from which release should people expect this behavior to be working again? We should update the content interface documentation to mention that.
I honestly lost track. Looking…
The key commit “follows” 2.26.1 so I’d say 2.26.2 should be good enough.
Okay, so that means the upcoming 2.26.9 will be the first release to reach stable with the problem fixed.
@gary-wzl This is already in the candidate channel. Would you mind to give it a try and let us know if it addresses your problem?
Thanks for the info.
I have core snap refreshed.
gary-wzl77@localhost:~$ snap list
Name Version Rev Developer Notes
core 16-2.26.9 2381 canonical -
A daemon-based app replied on shared content from another snap(docker-snap, in my case) still failed to launch. Looks like the bind mount is not executed while a daemon startup. Same behavior occurs If I disable/enable snap after relevant plug and slot are connected.
Can you please pastebin a few relevant files:
/var/lib/snapd/mount/snap.$SNAP_NAME.fstab
/run/snapd/ns/snap.$SNAP_NAME.fstab
Also can you please ensure that when you paste those the interface is in a known state (either connected or disconnected but please include this in your reply).
Sorry for the late reply, I let the request slip.
After I installed the snap locally and connected relevant interfaces manually. I have the following known states for relevant plug&slot connections
gary-wzl77@localhost:/run/snapd/ns$ snap interfaces | grep docker-app
:docker-support docker:privileged,docker:support,docker-app:privileged,docker-app:support
:network docker,docker-app
docker:docker-daemon docker:docker-cli,docker-app:docker-cli
docker:docker-executables docker-app
The content of file /var/lib/snapd/mount/snap.$SNAP_NAME.fstab, which looks good,
/snap/docker/x1 /snap/docker-app/x1/docker-env none bind,ro 0 0
But I got an empty file for /run/snapd/ns/snap.$SNAP_NAME.fstab and the bind mount is not added into *.fstab file.
If I simply removed the daemon: simple from my snapcraft.yaml file and redo the above steps (installation and slot&plug connections), I can see bind mount is saved in /run/snapd/ns/snap.$SNAP_NAME.fstab.
/snap/docker/x1 /snap/docker-app/x1/docker-env none bind,ro 0 0
Also I can manage to launch the app manually this time.
Interesting, thank you, I will investigate why this may be the case and get back to you.
@zyga-snapd Another open topic here.
I’ll check this out soon. I recently realized that logger.Noticef is broken and doesn’t log anything in snap-update-ns. I’d like to connect logs from s-u-n to the corresponding change that triggered it so that any failures are preserved in the change history.
Today when the update fails for whatever reason the error message is lost.
