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:
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?
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.
Should snap stop --disable actually disable the timer from running again in the future? I think it should.
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.
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.
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.
