Snap services start automatically

Bug #1664163 reported by Данило Шеган
16
This bug affects 2 people
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_DATA}/config.yaml" as the config file

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://github.com/snapcore/snapd/blob/master/interfaces/systemd/backend.go#L115

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-daemon-on-snap-install: false" would make us happy. Note that we do want the systemd service itself to behave just like today: restart on errors (or whatever option is set in snapcraft.yaml), we just don't want snapd to restart the service after install.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.