`stop` and `disable` should kill all processes regardless of daemon stop-mode

[Christopher Townsend]

In Multipass, a daemon is set to use `stop-mode: sigterm`, but when issuing `snap stop multipass` or `snap disable multipass`, any processes spawned by the daemon stay alive. This seems wrong since the user is explicitly wanting the whole snap stopped or disabled.

[Zygmunt Krynicki (zyga)]

Should you use "stop-mode: sigterm-all" instead? This will send the signal to all the tasks in the control group.

[Michał Sawicz (saviq)]

Let's step back, what we (and I suppose others, too) would like to avoid with this is services getting killed/restarted on snap refresh.

So maybe that's the wrong setting to use?
Maybe we need a `refresh-mode:` option?

[Zygmunt Krynicki (zyga)]

Using refresh-mode you can choose to "endure" the refresh or "restart" the app during the process. Using stop-mode you can choose how to stop the service. I'm not sure if that answers your question.

[Michał Sawicz (saviq)]

Still, is it by design that the services survive `snap disable` and `snap remove`?

I suppose this is a 1:1 mapping to systemd, so maybe that's expected... just surprising.

[Christopher Townsend (townsend)]

Right, so what I would like is on snap refresh, only sigterm is sent to the daemon process, ie, 'stop-mode: sigterm'. But on snap disable/stop, all processes are killed, which really should be the default regardless of what stop-mode is set to because who would really want processes running from the snap when the snap has been stopped or disabled?

[Zygmunt Krynicki (zyga)]

I don't think systemd has such a feature. Refresh stops and starts services, we don't differentiate stop-to-refresh from stop-to-...stop.

[Zygmunt Krynicki (zyga)]

I have expanded this topic on the forum https://forum.snapcraft.io/t/different-outcome-for-snap-stop-foo-vs-systemctl-stop-snap-foo-service-refresh-vs-stop/5901

[Christopher Townsend (townsend)]

@zyga,

Thanks for following up on this and posting the forum topic. I'll watch that topic, but I do understand that this is no different than systemd's behavior. But I still stand by my opinion that if a snap is stopped/disabled/removed, I would expect no running processes from that snap since snaps are supposed to be "self-contained sandboxes" and leaking processes just seems like the wrong thing to do in this case:)