I have multiple snap applications which use configuration files to determine where to find files that the snap needs to run. These configuration files are used from services which are expected to be normally running and as such, successfully stopped and started for refreshes. The issue I have is that these configuration files need to know where certain files/directories are, and we use various $SNAP_DATA, $SNAP, etc. based file paths in these configuration files, as the configuration files don’t understand environment variables nor do they understand relative paths. So on initial install, we use sed/jq/etc. to automatically populate these values in the configuration file during the install hook so the services startup properly. The problem I have is that these values are then invalid after a snap refresh, because the value of environment variables such as $SNAP, $SNAP_DATA directly contain the revision number rather than use the
- Is it safe to specify these configuration values as
currentinstead of the specific revision number as currently used?
- If it is safe, is there a good reason not to change future snapd versions to just make $SNAP, $SNAP_DATA, etc. use the
currentsymlink by default? Right now we can strip off the revision number and replace it with
currentbut it would be nice to not have to do that.
- What’s the recommended best practice for handling this situation? Should I reprocess the configuration files to use the updated value of $SNAP_DATA with the new revision number on every refresh? If so, what’s the best way to know what the previous revision number is? (the reason we need to know what the previous revision is that a user could also manually change the configuration values to point somewhere else the snap has permission to write to, say the home folder, removable-media, etc. and in this case we don’t want to overwrite it, so we need to see if the current value of those configuration items in the post-refresh hook matches what was set automatically for the previous revision - only then if it matches what we automatically set would we re-set the value to the new value for the next revision)
Also note that one reason it’s not desirable to use $SNAP_DATA with the current symlink is that running containers with overlayfs mounts with a target directory that has a symlink in it’s path causes weird kernel bugs. See https://github.com/opencontainers/runc/issues/586 for more details. However this is a small use case affecting a minimal number of snaps (i.e. greengrass and docker). Are there perhaps other issues with mounts that snapd performs using these variables that necessitate using the revision number explicitly?