Snap services start automatically
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
We have a problem with automatic daemon starts/restarts in snaps.
This is what we have:
1. A daemon service that requires a config file to run
2. A snap with this service defined as a "daemon: simple" command using "${SNAP_
3. A charm that generates said config.yaml after snap is installed and when database is available
This poses a conflicting requirement: snap installation does a service start, yet we can only generate the configuration after snap is installed (since that's when we've got the snap directory available to write to it). We also don't want to block snap installation on external conditions like database becoming available.
In general, for integration and management with charms, we'd like to have full service lifecycle control from within a charm (with HA units, we might want to "pause" only one unit, update the snap but not restart the service since it might require database changes), which basically just means: do not start the service automatically on install. So far, we work-around it by stopping the service right after install, but this leads to tracebacks anyway (on first install, no config present, afterwards, database schema not up to date).
The code that seems to do this unconditionally is at https:/
We'd like it to be optional: i.e. a snap can define a daemon that does not get (re)started on install. Eg. a simple option like "restart-
Changed in snapd: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |