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

Bug #1776295 reported by Christopher Townsend
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Wishlist
Unassigned

Bug Description

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.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

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

Changed in snapd:
status: New → Incomplete
Revision history for this message
Michał Sawicz (saviq) wrote :

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?

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

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.

Revision history for this message
Michał Sawicz (saviq) wrote :

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.

Revision history for this message
Christopher Townsend (townsend) wrote :

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?

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

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.

John Lenton (chipaca)
Changed in snapd:
status: Incomplete → New
Revision history for this message
Zygmunt Krynicki (zyga) wrote :
Revision history for this message
Christopher Townsend (townsend) wrote :

@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:)

Zygmunt Krynicki (zyga)
Changed in snapd:
status: New → Triaged
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers