While right now snaps offer a convenient way to register certain applications as daemons, we don’t yet expose a convenient way to manipulate them after installation. One needs to enable/disable the whole snap instead, which is a larger action.
So here is a quick proposal for implementing the manipulation of daemons via the snap command:
snap stop <snap>[.<app>] – Stops all daemons in the snap, or only the selected one if specified.
snap start <snap>[.<app>] – Starts all daemons in the snap, or only the selected one if specified.
snap restart <snap>[.<app>] – Restarts all daemons in the snap, or only the selected one if specified. Daemons which are not yet running will be started as well.
snap restart --reload <snap>[.<app>] – Reloads all daemons in the snap, or only the selected one if specified. Daemons that do not support reloading are restarted instead as long as they were already running (systemd’s try-reload-or-restart).
snap log <snap>[.<app>] – Shows logs for all daemons in the snap, or only the selected one if specified.
snap status <snap>[.<app>] – Shows human-oriented status summary for all daemons in the snap, or only the selected one if specified (systemd’s status).
For all commands, multiple <snap>[.<app>] parameters may be specified, but at least one must necessarily be provided.
do we really want to add this many toplevel commands? In the last iteration they were tucked away under the service subcommand, e.g. snap service stop [snap[.app]...]
For the first question, I assume you mean whether we can take multiple services at once. Yes, that sounds like a good idea.
For the latter, feels nicer to have them as first class commands. I’ve dropped the reload proposal in favor of restart --reload, though, and still thinking a bit about status. This feels a bit too open ended in this context and too similar to info, so it might change.
Without going into details of what commands to expose, I just want to send you down the path of caution as snap help is already pretty long and you don’t want to get to the point where we are with our snapcraft help which I need to rework.
Point taken, but the main problem with snapcraft’s help is not just the availability of the command name and summary in its help, which is what snap help does. The critical issue there is that every flag of every command is listed in that same global help page, and every individual command points there when called with --help, instead of having an individual page with proper details for that one command.
Thanks for taking up this topic; it is something that I’ve really missed over 15.04. FWIW, I like the proposal as @niemeyer gave it (snap start|stop|...) over 15.04’s (snap service start|stop|...). It feels like a natural companion to snap run. You run a (non-daemon) command, and you start/stop/restart/reload daemons.
stop, start, restart and status seem to be duplicating systemd functionality. Which I guess is fine, since there might not actually be a systemd running.
This proposal still lacks the ability to enable or disable daemons, which is what is needed right now. We need to control what starts after a reboot and what does not, without disabling the entire snap.
It would be good if daemons could be declared to be disabled by default, requiring the operator to explicitly enable them after installation of the snap.
It’s not duplicating systemd functionally, but rather using it in a more convenient and purpose-specific way.
About the enabling and disabling, do you have more details? Initial gut feeling is that this is strange to be doing from the outside. It sounds more like something that configuration should be able to do, instead of requiring people to fiddle with individual services manually.
Requiring enable/disable to be done from the inside requires every snap to implement those hooks. And implement them in a standard way so it is discoverable. I assert that most snaps will not, and will arrogantly assume that their daemons should be running, because less code and less configuration is good from the perspective of a snap author and provides a better user experience for most installations. However, some users need to manage their precious resources and need control beyond what the snap author provides, and at the moment the only control they have is to uninstall the snap (and destroy any related data). Laptops would be the main use case, where resources like RAM and power are tight and you often want to shut down services not related to the task at hand.
I don’t think the implementation should be complex. I particular, I don’t think any complex dependency management is needed or wanted (if you explicitly shut down the lxd daemons, you should expect anything relying on them to fail). I think the systemd implementation would be to dump a .override file in the right place. I don’t know about non-systemd environments.
Allowing snaps to enable/disable their own daemons or daemons of other snaps via an interface may be useful, but I think is a separate topic.
I think the verbs should match systemd, upstart & init.d meanings or users will get confused. If you want start and stop to be persistent, rename them to enable and disable. Or have four commands like systemd:
Enabling units should not be confused with starting (activating) units, as done by the start command.
Enabling and starting units is orthogonal: units may be enabled without being started and started without
being enabled. Enabling simply hooks the unit into various suggested places (for example, so that the unit
is automatically started on boot or when a particular kind of hardware is plugged in).
Hmm, now I read that there is another use case for the future, where snapd starts daemons when hardware devices are plugged in or powered on.
snap enable and snap disable already exist - they could probably be extended to take [.app] but it wouldn’t be exactly the same behavior as systemd enable/ disable when used for the entire snap.
)
that makes everything so much clearer.