Remove is called after snap services are stopped

[Konstantinos Tsakalozos]

Hi,

The remove hook runs after any services provided by the snap are stopped.

There doesn't seem to be a way to perform any cleanup by interacting with the services. Let me provide an example, in the case of microk8s (that is a full kubernetes cluster) we want to release resources such as pods, this needs to be done while the kubernetes services are up.

This bug is dicussed in the forum: https://forum.snapcraft.io/t/cleanup-before-services-go-down/5802

Thanks

[Paweł Stołowski (stolowski)]

Thanks for providing a use case with this bug report. We might think of a pre-remove hook, but this needs discussion (simply chaning current hook to run before services are stopped is of course not an option anymore).

As for interacting with services, you can do that with `snapctl start|stop|restart ..` (see "snapctl start --help" for an example), but I'm not suggesting to start the service back just to do the cleanup, just mentioning in case it's useful in some other case. We indeed may need a pre-remove hook to cater for all possible cases.

[Samuele Pedroni (pedronis)]

yes, a "pre-remove" hook seems a reasonable request, afaiu it would run before anything else in a remove and again only in the case of a full remove of the snap

[Paweł Stołowski (stolowski)]

PR: https://github.com/snapcore/snapd/pull/6232

[Samuele Pedroni (pedronis)]

We discussed this a bit further and is a bit unclear what the expectations would be for this new hook, in general right now with the current hook we do a best effort to stopping services and then we call it.

I understand the naive expectations for the new hook would be that the services are running, but what if they failed, or some are not running? would snapd be expected to do a best effort to getting them to run them before invoking the hook?

We should keep in mind in general remove can be used by users also on snaps in a broken state.

Would the code you imagine be running in the new hook be ok if some of the services are failed or not running, in general in the end we would ignore the hook errors and continue with remove. We do the same already with the current hook.

[Samuele Pedroni (pedronis)]

Basically we fear the convenience of the new hook would be misleading. Any remove related hook would need to be ready to deal with various forms of broken state possibly.

[Dmitrii Shcherbakov (dmitriis)]

To add more context to the feature request, I have the following use-case:

* an OVS bridge gets created during the snap initialization;
* on snap removal it needs to be removed;
* however, by the time the code in the remove hook starts getting executed, all of the services required to do that are stopped (namely, ovsdb and vswitchd).

To make it more clear: the bridge is registered in the kernel (openvswitch kernel module), however, the tools used to trigger the removal talk to the user-space services which do the actual work of talking to the kernel.

In essence, I currently have to start those services back up before trying to remove the bridge:

```
cat snap/hooks/remove
#!/bin/bash
set -ex

snapctl start microstack.ovsdb-server
snapctl start microstack.ovs-vswitchd

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/current/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu
$SNAP/usr/local/bin/ovs-vsctl --if-exists del-br br-ex

snapctl stop microstack.ovsdb-server
snapctl stop microstack.ovs-vswitchd
```

Having pre-remove would allow me to get rid of the manual startup of services in the remove hook.