issue on updating parallel installed snap via hook cause snapd does not remap the servicename correctly to identifier of paralell snap, it have to be nexcloud_1.apache in this example not nextcloud.apache.
We currently do not support automatic remapping of snap name in snapctl. This will likely be addressed later, but at the moment it is advised to use $SNAP_INSTANCE_NAME inside hooks or code.
That is:
snapctl restart nextcloud.apache
should be updated to:
snapctl restart "$SNAP_INSTANCE_NAME.apache"
Yeah… and requiring that snaps change so as to not be broken in this scenario isn’t ideal either. Can we increase the priority of the remapping?
1 Like
sorry, to be clear, I don’t see how to do a remapping that would work consistently (which might speak more of my ability to “see” things than anything else). Snaps should not be assuming their name anyway, because the name could change for a number of reasons, so any snap that hardcodes its names in runtime is going to break in those cases. Parallel installs is just the case you get to see today.
Uh. Hard to use snapctl restart in that case 
.
This is silly. I’m not going to be rewriting my snaps just so this feature works.
1 Like
The issue here is that in general for all the snapctl commands the snap name should be possibly implicit/optional. When the service commands were added to snapctl this was not taken into account.
We need to think how we can untangle ourselves from that without breaking already existing snaps.
3 Likes
Yes, this is exactly the thought I had when utilizing this feature originally. Now it makes even more sense. snapd obviously knows this information given the cookie.
Hi all,
I know this is like a 4 years old thread, but looks like the issue is still here. Is there any progress on this matter?
1 Like