When you declare apps in your
snapcraft.yaml, it results in a binary wrapper being generated upon install and placed into
/snap/bin/, named after your package and app name (note that if the app is a service, this wrapper is instead a systemd .service file).
That wrapper contains most of the environment under which the application will run. The two environment variables that are most relevant to this question are
SNAP_USER_DATA. You can find more information about these in the documentation, but I'll describe them here as well:
SNAP_DATA is a system-wide writable area (in
/var/snap/). This might be used to host logs for services, for instance.
SNAP_USER_DATA is a user-specific writable area in the home directory of the user running the application (specifically
/home/<user>/snap/). This might be used for user-specific configuration files, etc.
Both of these directories are very important to the upgrade/rollback functionality, since both of them are versioned. That is, each revision of a given snap has its own copy of these directories. Let me explain with an example.
Say you install revision 1 of the "foo" snap. That will create two directories:
Now say "foo" uses both of these. Maybe it has a service that hosts a database in
SNAP_DATA, and a binary that uses config files in
Now revision 2 of "foo" is released, and it's automatically updated. The first thing that happens is that
/var/snap/foo/1 is copied into
/home/<user>/snap/foo/1 is copied into
/home/<user>/snap/foo/2. Then the new revision is fired up. It should notice that it's running on old data, and maybe it has some database migrations to run to the database in
SNAP_DATA. It does that, and away it goes.
Now say those migrations fail for whatever reason, and this application needs to be rolled back. It begins using the old revision of the /snap/foo application, where
SNAP_DATA was pointing to
SNAP_USER_DATA was pointing to
/home/<user>/snap/foo/1. This picks things up on the old version at the point before the migrations were run, since those operations were run on a copy of the data.
Long story short: don't use the
home interface to store data you can be storing in
SNAP_USER_DATA, since they're an integral part of the upgrade/rollback strategy. Take advantage of them!
UPDATE for v2.0.10:
Two new data directories were also introduced:
SNAP_COMMON sits alongside
SNAP_DATA, but is specifically unversioned. Every revision of the specific snap has access to this directory, so it's not copied upon upgrade/rollback etc. This might be used for particularly large, unversioned files (e.g. raw data that isn't really version-specific).
SNAP_USER_COMMON sits alongside
SNAP_USER_DATA, but is again specifically unversioned. It might be used for storing non-version-specific data per user.
UPDATE for v2.15:
The files placed within
/snap/bin are no longer wrappers that define the environment, but symlinks to
/usr/bin/snap. So the way to determine the environment under which an application runs would be to use
snap run --shell <snap>.<app>, for example:
$ sudo snap install hello-world
$ snap run --shell hello-world
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ env | grep SNAP
Developer mode, or
devmode in short, enables developers and users to install snaps without enforcing security policies. E.g.
sudo snap install notes --devmode
When installed this way, snaps behave in a similar way to traditional .deb packages in terms of accessing system resources. That is, snaps have access to the system without being restricted by app isolation and interfaces.
Developer mode is useful when:
- Testing a snap in the first stages of development to ensure it runs as expected
- Temporarily bypassing security enforcement if there is not yet an interface available that controls a particular system access required by the snap
As a developer, you can also relax security requirements at the snapcraft.yaml level by declaring
devmode confinement instead of
You'll be then flagging users that this app specifically needs to be installed with
--devmode to work. Not specifying the switch will result in failure to install.
That is, users will have to specifically acknowledge that they will install your snap in developer mode.
Testing a service
To test a service it must be installed first. Once it is installed, systemd's
systemctlcommand can be used to see if the service starts and runs as expected, for example:
Finding the logs
journalctlcommand can be used to inspect the messages that the service sends to
stderr, for example:
Services may log additional data to syslog (
/var/log/syslog) or to custom log directories. Note that custom log directories must be in a path that the service can write to (usually
Getting a core dump
To enable core dumps you have to configure a place to write them to through sysfs. For instance you can use
to ensure that your coredumps get written into the
/tmpdirectory regardless of where
CWDof the process that received a signal was.