I appear to have ended up in a catch-22 situation. I have a snap that contains a service, which relies on an interface (network-control) to be connected. If the interface is not connected, the service fails due to a
Permission denied error.
So when I try to install the snap, the service fails (since the interface is not yet connected), and the snap installation is rolled back altogether. Therefore I never have the chance to actually connect the needed interface.
What are my options here? Is there a way to “force-install” the snap (and disregard the initial service failure) in order to connect the interface and then run the service?
Right now the best thing to do is to disable the interface in an install hook with something like:
snapctl stop --disable "$SNAP_NAME.<service-name>"
and then you could have a
connect-plug-network-control interface hook for the necessary interface which runs after the network-control interface gets connected, that enables and starts the service with:
snapctl start --enable "$SNAP_NAME.<service-name>"
Thanks @ijohnson, actually just came across your other post on this topic. Sounds like a sensible solution.
I have often found myself wishing there was an “optional” flag that could be set for service definitions, which would allow the install to still succeed even if a service fails to start the first time around. Though I suppose the “disable on install” hook you describe has a similar net effect.
We have started to look at a flag in the yaml or something like this which does that, but no more details on that yet. When it’s available to play with, we will post something on the forum about it.
A bit of a throwback - but figured I’d share in case anyone comes across this - it looks like this is now available as the
apps.<app-name>.install-mode option (docs).