Different behaviour for explicit service stops vs those done for refresh

snapd
1

This topic is an extension of the conversation from https://bugs.launchpad.net/snapd/+bug/1776295

The bug report states, as follows:

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.

The following conversation states the desire more clearly:

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?

Looking at the code it doesn’t seem possible today to say stop-mode: sigterm-all but still make it stop-mode: sigterm when doing a refresh. Refresh with refresh-mode: endure just skips touching a service.

2

Is there any update on this issue?

In MicroK8s we have a containerd daemon that starts child processes for all user workloads. On refresh we want to stop only the containerd daemon. On a normal service stop we want to additionally stop the user workloads.

An effect of us not being able to stop the child processes is that a system shutdown takes 90+ seconds until the workloads are removed forcefully. See https://github.com/ubuntu/microk8s/issues/2773