Service management

wiki · February 11, 2018, 11:01pm

The majority of snaps expose their functionality via applications that run on the local system. Most of these applications are started either from the command line, the graphical desktop, or as services that run automatically.

A single snap may provide multiple applications and services. With a database snap, for example, you might expect an interactive client application alongside the service daemon.

Snaps manage their own services without the need for manual intervention. However, experienced administrators may want to interact with a snap’s services to help improve their integration with the local environment.

For that reason, snapd offers a set of commands to allow a snap’s services to be inspected and their statuses changed.

User and root-level services

Prior to the release of snapd 2.66, all services were run with root-level access. The snap commands used to manage these services would require equivalent access, such as by preceding snap with sudo.

With the release of snapd 2.66, there is now distinction between user-level services and root-level services. User-level services can be listed and managed without requiring any privilege escalation, while services running as root still require equivalent access.

Listing services

The snap services command lists the active and enabled state of snap-based services for the current user, or with the additional --global argument, for the entire system.

$ sudo snap services --global  
Service                    Startup  Current   Notes
lxd.activate               enabled  inactive  -
lxd.daemon                 enabled  active    socket-activated
lxd.user-daemon            enabled  inactive  socket-activated
multipass.multipassd       enabled  active    -
nextcloud.apache           enabled  active    -
nextcloud.logrotate        enabled  inactive  timer-activated
nextcloud.mysql            enabled  active    -
nextcloud.nextcloud-cron   enabled  active    -
nextcloud.nextcloud-fixer  enabled  active    -
nextcloud.php-fpm          enabled  active    -
nextcloud.redis-server     enabled  active    -
nextcloud.renew-certs      enabled  active    -

Adding a snap name as an argument will list only those services added by that snap, or with <snap-name>.<app>, for a single app:

$ snap services lxd.daemon    
Service     Startup  Current  Notes
lxd.daemon  enabled  active   socket-activated

The output includes the service name, whether the service is started when the system starts up, and whether it’s currently running.

Restarting, stopping and starting services

Services are restarted using the snap restart <snap name> command. This may be necessary if you’ve made custom changes to the snap application, for example, which the service needs to reload.

Using both the snap name and the specific app enables you to target a specific service:

$ snap restart lxd.daemon
2024-11-21T21:51:06+01:00 INFO Waiting for "snap.lxd.daemon.service" to stop.
Restarted.

The option to perform an operation on all of a snap’s services, or on one specific service, is common to all commands that operate on services.

If a service supports reloading, enabling the service to remain running while loading a new configuration, this can be requested with the --reload option:

snap restart --reload lxd.daemon

The start and stop commands control whether a service should be currently running.

Adding the --system argument can be used to manage system-level services, while --user and --users=all can be used to manage services for the current user, or for all users, respectively.

The following combination is also valid:

snap {start,stop,restart} --system --users=all my-snap

As root, the default behavior of not specifying anything is the equivolent of:

snap {start,stop,restart} --system my-snap

If operating on a snap that contains a user-service as root, the switch --user or --users=all must be provided to indicate that it’s intentional, otherwise an error will be thrown.

To prevent a service from starting on the next boot, use the --disable option:

snap stop --disable lxd.daemon

The start command includes an --enable option to re-enable the automatic starting of a service when the system boots:

snap start --enable lxd.daemon

Disabling and enabling user-services

User-services cannot be disabled or enabled individually for users currently, they can only be enabled globally or disabled globally (i.e for all users).

Inspecting logs

If you need to see the log output for a snap’s services, use the logs command. As with the services command, you can specify either a snap name to see the logs for all the services it contains, or the name of a specific service within a snap:

$ sudo snap logs lxd
2018-09-14T10:38:23Z lxd.daemon[11096]: => LXD is ready
(...)

$ sudo snap logs lxd.daemon
2022-07-15T17:13:04+01:00 lxd.daemon[1389234]: => LXD exited cleanly
2022-07-15T17:13:04+01:00 lxd.daemon[370462]: ==> Stopped LXD
2022-07-15T17:13:04+01:00 lxd.daemon[370462]: => Stopping LXCFS
2022-07-15T17:13:04+01:00 lxd.daemon[555302]: Running destructor lxcfs_exit
2022-07-15T17:13:05+01:00 lxd.daemon[370462]: ==> Stopped LXCFS
2022-07-15T17:13:05+01:00 lxd.daemon[370462]: => Cleaning up PID files
2022-07-15T17:13:05+01:00 lxd.daemon[370462]: => Cleaning up namespaces
2022-07-15T17:13:05+01:00 lxd.daemon[370462]: => All done
2022-07-15T17:13:05+01:00 systemd[1]: snap.lxd.daemon.service: Deactivated successfully.
2022-07-15T17:13:05+01:00 systemd[1]: Stopped Service for snap application lxd.daemon.

By default, only the last 10 lines are output. This can be changed with the -n= option which can accept either a number or all for the entire log:

snap logs -n=all lxd.daemon

Adding the -f option will keep log output open so you can follow new entries as they occur:

$ sudo snap logs lxd -f

The size and rate of log output can be limited by placing a snap within a quota group. See Journal log limits for more details.

rpjday · January 9, 2022, 3:20pm

This page (and elsewhere) should be more explicit about which “snap” commands need sudo, and which don’t. For example, on this page, there is the example:

$ sudo snap services lxd

but that command does not need sudo privilege. Conversely, running:

$ snap logs lxd

strangely prompts me for my password, and does require sudo. In fact, in the last section, the different variations of “snap logs” mix and match using sudo, which can be confusing.

degville · January 10, 2022, 11:08am

Thanks for bringing this up. I agree that it’s important we’re consistent. I’ve edited the examples you gave and I’ll keep an eye out for other inconsistencies when editing other docs.

Another option is that we remove sudo from the docs entirely. The host system will either prompt you for a password or inform you that sudo is needed, and if you’re logged in to the store, you won’t be required to enter a password anyway. Also, some systems simply don’t use sudo. This might be the best way forward, but it does mean we lose the subtle documentation characteristic that sudo implies some privilege, usually for a destructive or privacy related reason. Happy to hear opinions on this.

rpjday · January 10, 2022, 11:40am

Personally, I like to see the distinction between commands that need sudo, and those that don’t, but that’s just me.

Lin-Buo-Ren · January 10, 2022, 11:53am

I would say that the subtle documentation characteristic that sudo implies some privilege is more important, and it matches the general usecase where most(?) users don’t log in to their Ubuntu accounts.

rpjday · January 10, 2022, 12:57pm

My fondness for using “sudo” in command examples is sort of like the above – for me, it’s a visual warning that what I’m about to do requires root privilege because it is potentially dangerous, which typically makes me take a second and wonder, “Hmmmm … how can I screw this up if I make a mistake?”

Conversely, if I see something that requires “sudo” that I wouldn’t have thought needed it, it makes me wonder, “OK, why would this operation not be available to regular users?” Perfect example: “snap logs”, which made me assume that looking at logs might be a security hole if anyone was allowed to peruse them.

In any event, for me it’s an aesthetic thing, and I will defer to those higher up the food chain.

degville · January 10, 2022, 1:50pm

Thanks for the comments (and @Lin-Buo-Ren). For what it’s worth, I agree about keeping sudo too. But there had been some discussions internally about this and it’s good to have some outside feedback we can refer to.

rpjday · January 15, 2022, 7:33pm

I would mention the snap restart “–reload” option:

[restart command options]
      --no-wait      Do not wait for the operation to finish but just print the change id.
      --reload       If the service has a reload command, use it instead of restarting.

And for “snap logs”, is it worth mentioning the “-n=” option to show either that number of lines, or “all”?

degville · January 18, 2022, 5:39pm

I’ve updated this doc with your suggestions. Thanks!

rpjday · July 30, 2022, 4:51pm

Is there a way to enable/disable a specific service of a snap without starting/stopping it? I can see all of the variations of stop and start with options, but I don’t see the magic incantation that will, for example, disable a specific snap service while still leaving it running.

degville · August 1, 2022, 1:49pm

I don’t think there is a way to disable a specific service within a snap and ask snapd to leave it running.

rpjday · August 2, 2022, 8:20am

I believe that is correct; kind of weird that something so straightforward can’t be done. Oh, well.

pmeulengracht · October 23, 2024, 11:49am

@degville Updates coming with 2.66

Listing services

If snap services is executed as root, then the behavior is as described today

If snap services is executed as non-root, then it will now list the active/enabled state of the user-services for the current user. Additionally, the --global flag is introduced in this case to get the default output (for the root case). Example given below,

philip@services:~$ snap services
Service                                              Startup  Current   Notes
snapd-desktop-integration.snapd-desktop-integration  enabled  active    user

philip@services:~$ snap services --global
Service                                              Startup  Current   Notes
snapd-desktop-integration.snapd-desktop-integration  enabled  -         user

Start, stop and restart services

With the introduction of management for user-services, the following new switches are available to provide better control of which services you start/stop/restart.

--system

Which will indicate the operation should include system services.

--user or --users=all

Which will indicate the operation should include user services, for either the current user only (--user), or for all users on the system (--users=all)

I.e the following combination is also valid: