One snap may contain many binaries and their support files. The binaries are exposed to the host system via an
apps: section in the
command: refers to one binary in the snap which needs to be made available to the host. Not all binaries may need to be listed.
For example if an audio processing application
audiocoder internally uses the
ffmpeg command to encode files, the
audiocoder command may need to be listed, but the
ffmpeg binary may not. This is all dependent on whether it’s expected that the end-user will need to run the binary directly or not. If not, do not list them in the
To specify multiple command, add a section for each one, with the necessary
plugs required by each, which may differ. In this example a command line binary and a graphical application are contained in a snap, but the graphical command requires more plugs.
plugs: [network, desktop, desktop-legacy]
Snaps may also contain daemons which can automatically start/stop, and be controlled by the user using standard commands such as
Apps can either be defined as
If set to
simple, it is expected that the command configured is the main process.
Oneshot, it is expected that the command configured will exit once it’s done (won’t be a long-lasting process).
When set to
forking, it is expected that the configured command will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons.
If set to
notify, it is expected that the command configured will send a signal to systemd to indicate that it’s running.
Optionally developers can set a
stop-command which represents the command required to stop the daemon.