How to disable a timer service in a snap?

snapd
#1

Hi folks, I think this is likely a snapd bug, but just wanted to post on the forum for clarity on the situation.

I have this simple snap which just prints off something every 1 minute:

name: every-1-min
version: '0.1'
summary: every-1-min
description: every-1-min prints something off to the logs every 1 minutes
grade: stable
confinement: strict
apps:
  every-1-min:
    command: echo "hello"
    daemon: oneshot
    passthrough:
      timer: 00:00-24:00/1440
parts:
  my-part:
    plugin: nil

And when I install the snap, the service shows up as disabled:

$ sudo snap install --devmode every-1-min_0.1_amd64.snap 
every-1-min 0.1 installed
$ snap services
Service                  Startup   Current
every-1-min.every-1-min  disabled  inactive

However, it’s still running fine:

$ sudo journalctl -ef -u snap.every-1-min.every-1-min.service 
-- Logs begin at Thu 2018-09-06 12:58:10 CDT. --
Sep 27 08:38:13 my-computer systemd[1]: Starting Service for snap application every-1-min.every-1-min...
Sep 27 08:38:13 my-computer every-1-min.every-1-min[21791]: hello
Sep 27 08:38:13 my-computer systemd[1]: Started Service for snap application every-1-min.every-1-min.
Sep 27 08:39:05 my-computer systemd[1]: Starting Service for snap application every-1-min.every-1-min...
Sep 27 08:39:06 my-computer every-1-min.every-1-min[21913]: hello
Sep 27 08:39:06 my-computer systemd[1]: Started Service for snap application every-1-min.every-1-min.

The confusion is that I can’t seem to stop this service from continuing to run even with snap stop --disable every-1-min.every-1-min:

$ sudo snap stop --disable every-1-min.every-1-min
Stopped.

The only way to disable the timer it seems is to disable the entire snap:

$ sudo snap disable every-1-min
every-1-min disabled

Now, as a tangent, I tried changing the daemon: oneshot to daemon: simple to see if that changed anything, and it just makes it so that the Starting Service for snap application every-1-min.every-1-min... line isn’t printed off to the logs anymore when the daemon runs (which makes sense). However I still see the same behavior where I can’t disable just the timer service with snap stop --disable and need to use snap disable.

Questions:

  1. What’s the appropriate value for daemon for a service that has a timer? In my case the service is a simple command that gets run and finishes, so I assumed oneshot, but perhaps simple is better? Does it matter?
  2. Should the service really show up as “disabled” after installing? I think it shouldn’t. I think it should be “stopped”, i.e. Startup -> enabled and Current -> inactive, except during the time in between when the application is started by the timer and when it stops, so for example if the command was sleep 60 & echo "done", during the 60 seconds the service was sleeping Current should be active.
  3. Should snap stop --disable actually disable the timer from running again in the future? I think it should.

Ping @mborzecki

#2

You should use the same value as you’d use when writing the service file for systemd yourself. I’ve used simple, oneshot should probably work too. Keep in mind that if the service is active at the time the timer expires, another one won’t be started

This looks odd indeed. From a quick look at the code snap stop <name> affects the service only, timers and sockets are not touched at all. As a workaround you’d have to manually stop and disable the timer using systemctl stop --disable snap.every-1-min.every-1-min.timer.

snapd should probably glow the ability to stop/start sockets and timer when called via snap [stop|start]. I think there’s also a little uncertainty about what the user wants to do. Since the service is socket/timer activated, when calling snap start <svc> should the service start or just the socket/timer?

I think it’s the same problem, snapd is only checking the status of the service, and not the socket or timer.

#3

I think this is this bug: LP: #1784384.

#4

I’ve just hit this issue as well.

It is further detailed in the following thread “How to manage services with sockets/timers” and tracked in LP1842257 & LP1842258. However there doesn’t seem to be much activity around that since a while. Is it actively tracked? Is there any ETA for a fix?

Thanks.

#5

Hi everyone,

I created a small example snap to investigate this. I tested using snapd latest/stable.

  • My test shows that using snapd latest/stable the timer based trigger of the service can be disabled with: sudo snap stop --disable <snap-service>. This seems to contradict the claim and this bug report? My conclusion is based on the journal showing it is not started. The snap services output is arguable confusing so that is disregarded.

  • My test shows the service status at startup as enabled. This seems to contradict the claim?

  • In investigated what happens behind the scene with disabling a timer based service. It is actually the timer unit that is disabled and not the service itself, which arguable makes sense from a systemd point of view. This can be inspected with systemctl status snap.<snap-name>.<service-name>.timer

As suggested, the services status is arguably not communicated to the user with sufficient detail. In my test the output from snap services does not change after disabling the service. Additional info showing the status of associated triggers such as sockets and timers might be one approach to clarify things while sticking to the systemd way of things.

The good news is that there are plans to review services related behaviours.

#6

Hello,

Thanks for the quick response.
I gave a shot to a small example myself and sudo snap stop --disable <snap.service> does indeed disable it.

However marking the service as install-mode: disable in the snapcraft.yaml (my actual use-case) does not result in the (reasonably?) expected behavior, the service is running while I would expect it not to. I get a similar behavior invoking snapctl stop --disable <snap.service> in the install hook.

#7

Hi artivis,

We are currently working on services, to improve inconsistencies and user experience. This is the first ste: https://github.com/snapcore/snapd/pull/13128.

Your finding was added to the list of things to consider.

Will try and post progress on the topic in this thread.

1 Like