What is the difference between running a snap’s app, as defined in the snapcraft.yaml file,
- directly using /snap/bin/mysnap
- manually by first getting a shell with
snap run --shell mysnap and then executing the corresponding command wrapper in $SNAP?
Here is an example to help you understand the situation:
When starting the chromium snap, usually, one would execute /snap/bin/chromium.
To improve my understanding of how snaps function, I opened a shell using
snap run --shell chromium and tried executing
$SNAP/command-chromium.wrapper. Then, however, I got an error, that shared libraries are missing.
/snap/chromium/949/usr/lib/chromium-browser/chrome: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
But according to find, these are located in /snap/chromium/949/usr/lib/x86_64-linux-gnu/libX11.so.6
I also tried adding the directory to
LD_LIBRARY_PATH, which did not work either.
My question is the following: Why does chromium find the libraries when beeing called “normally/directly,” but not when beeing inside the snap’s shell?
You can find chromium’s snapcraft.yaml here: https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/tree/snapcraft.yaml
The short answer to this is that those libraries would be found if the chromium snap used command-chain like so:
instead of the current:
command: desktop-launch chromium-browser.launcher
The distinction being that when using
snap run --shell, snapd will execute everything in the command-chain, before dropping you into the shell. In this case the desktop-launch script is also run.
You can probably workaround this for yourself if you manually executed the desktop-launch helper first:
$ snap run --shell chromium
$ $SNAP/desktop-launch $SNAP/chromium-browser.launcher
Thanks for your answer! I really appreciate your efforts.
However, since I am trying to run chromium by executing
$SNAP/command-chromium.wrapper, the desktop-launch script is already run.
I assume, snapcraft creates a command wrapper for every app, which consists of the contents of the command-property from the snapcraft.yaml file.
The command-chromium.wrapper contains:
exec "$SNAP/bin/desktop-launch" "$SNAP/bin/chromium.launcher" "$@"
How can it be, that manually executing the wrapper file is any different than what /snap/bin/chromium does?
Let me know if I haven’t described the problem well enough.
Ah right, so in this case you are correct that chromium is already running the desktop-launch script. However it’s not running the snapcraft-runner script, if you look at the generated snap.yaml at meta/snap.yaml, the app section for chromium has this:
command: snap/command-chain/snapcraft-runner $SNAP/command-chromium.wrapper
So to amend my previous recommendation all you need to do then is run through the snapcraft-runner:
$ snap run --shell chromium
$ $SNAP/snap/command-chain/snapcraft-runner $SNAP/chromium-browser.launcher
Ahhh, that’s it! I didn’t know the snap.yaml file. Thanks!
This raises another question: Is the
snap/command-chain/snapcraft-runner always the same? In case it is, wouldn’t it be useful to automatically execute the runner when manually entering the shell? Is there a reason why this isn’t done?
It is usually there if your snap was built with a newish version of snapcraft, however there are perfectly fine snaps built from a long(ish) time ago from before snapcraft created this file so it’s not required for a snap to have this file in it.
It would automatically be done by snapd when the
snap/command-chain/snapcraft-runner is put in the
command-chain in the snap.yaml.
Snapcraft will add this script to the
command-chain in the generated snap.yaml for you if the author of the snap does
adapter: full instead of the default behavior to use
adapter: legacy. (though snapcraft may also automatically switch you to the non-legacy behavior if you just specify
command-chain for an app, I’m not sure). Regardless, changing that probably falls upon @oSoMoN unless you want to submit a MR to the chromium snapcraft repo on launchpad.
All right. Thanks for the explanation.