Services and daemons

When creating snapcraft.yaml to build a new snap, a snap’s executable component can be either exposed as a command or run as a background service or daemon.

For details on how to expose an executable from its constituent parts, see Defining a command.

A snap daemon or service behaves the same as a native daemon or service, and will either start automatically at boot time and end when the machine is shutdown, or start and stop on demand through socket activation.

Services and daemons can also be managed within a snap, such as via a hook, with the snapctl.

If you need to add user configurable options to your service or daemon, such as which port it should use, see Adding snap configuration.

Defining a daemon

To define an executable as a daemon or service, add daemon: simple to its apps stanza:

    command: bin/
    daemon: simple

The value for daemon: can be one of the following:

  • simple
    Run for as along as the service is active - this is typically the default option.
  • oneshot
    Run once and exit after completion, although the process is still considered running.
  • forking
    The configured command calls fork() as part of its start-up and the parent process is then expected to exit when start-up is complete. This isn’t the recommended behaviour on a modern Linux system.
  • notify
    Assumes the command will send a signal to systemd to indicate its running state. Note this requires usage of the daemon-notify interface.

In addition to the above types of daemon or service, the following can be set to help manage how a service is run, how it can be stopped, and what should happen after it stops:

  • after
    An ordered list of applications the daemon is to be started after. Applications must be part of the same snap.
  • before
    An ordered list of applications the daemon is to be started before. Applications must be part of the same snap.
  • install-mode
    Defines whether a freshly installed daemon is started automatically, or whether startup control is deferred to the snap. The snap could then use snapctl with a hook, for instance, or another management agent. Can be enable (default) or disable.
  • post-stop-command
    Sets the command to run from inside the snap after a service stops.
  • refresh-mode
    Controls whether a daemon should be restarted during a snap refresh. Can be either restart or endure (to not restart). Defaults to restart.
  • restart-condition
    Defines when a service should be restarted, using values returned from systemd service exit status.
    Can be one of [on-failure|on-success|on-abnormal|on-abort|on-watchdog|always|never].
  • restart-delay
    The delay between service restarts. Defaults to unset. See the systemd.service manual on RestartSec for details.
    Time duration units can be 10ns, 10us, 10ms, 10s, 10m.
  • sockets
    Requires an activated daemon socket, and works with the network-bind interface to map a daemon’s socket to a service and activate it.
  • socket-mode
    The mode of a socket in octal.
  • start-timeout
    Optional time to wait for daemon to start.
    Time duration units can be 10ns, 10us, 10ms, 10s, 10m.
  • stop-command
    Used to define a command from inside the snap to stop the service or daemon.
  • stop-timeout
    The length of time to wait before terminating a service.
    Time duration units can be 10ns, 10us, 10ms, 10s, 10m. Termination is via SIGTERM (and SIGKILL if that doesn’t work).
  • timer
    Declares that the service is activated by a timer and that the app must be a daemon. See Timer string format for syntax examples.
  • watchdog-timeout
    This value declares the service watchdog timeout. For watchdog to work, the application requires access to the systemd notification socket, which can be declared by listing a daemon-notify plug in the plugs section.
    Time duration units can be 10ns, 10us, 10ms, 10s, 10m.

For further details, see Snapcraft app and service metadata.

Last updated a month ago.