Process lifecycle on snap refresh

snapd
21

Okay, after may conversations on the topic in various meetings, we’d like to revisit this and push something forward.

Here is a new proposal that takes into account those conversations:

Problem statement

It is reasonable for some workloads to remain running across refreshes. The typical case is managers of containers or virtual machines that want to remain alive while the software that enables them to run gets updated.

Proposal

We’ll introduce a new option that can be used under the application definition scope in snap.yaml and snapcraft.yaml:

apps:
    myapp:
        command: ...
        daemon: ...
        refresh-mode: [ restart / endure ]

The default for this option is restart for daemons and endure for other applications. Initially only changing daemons will be accepted, but we plan to support changing that for other applications too.

As implied, when a daemon is set to endure it won’t be restarted during a refresh. Additionally:

  • It will lose write access to its per-revision data ($SNAP_DATA)
  • It won’t lose access to the data common across revisions ($SNAP_COMMON)
  • The current symlink will be moved to the new revision as usual
  • Pre and post refresh hooks will work as usual
  • The security profiles will be updated (see caveats below)

Caveats

In the first implementation of this feature the security profiles for the application will be updated during the refresh, meaning the old process will get the same permissions as the new process. This is not ideal, but it’s a reasonable compromise to get something working sooner, and can be addressed in a future release without breakages.

Comments

How does that sound? Anything we should watch out for or consider further around this feature?

3 Likes