Command line interface to manipulate services

snapd
41

I agree, they should go hand-in-hand. When they get out of sync for some reason, that’s when snap services should point it out.

1 Like
42

At least for timers, the active state of the service and the timer will be out of sync most of the time as the timer is active while the service is not.

For sockets, we can have many of those. Each corresponds to some ListenStream. I can see a case when one would want to disable/stop one socket, while leaving the rest enabled/started.

How about this format for snap services:

$ snap services
Service                                       Startup   Current   Notes
lxd.activate                                  enabled   inactive  -
lxd.daemon                                    enabled   inactive  -
lxd.daemon.unix                               enabled   active    socket
test-snapd-timer-service.random-timer         disabled  inactive  timer
test-snapd-timer-service.regular-timer        enabled   active    timer

For timers, the Current and Startup columns, show the status of the timer unit. Maybe we could show the status of the *.service associated with the timer in the notes column? Eg.:

$ snap services
Service                                       Startup   Current   Notes
...
test-snapd-timer-service.regular-timer        enabled   active    timer,running

Although the output may be confusing at times as the timer service can be started outside of defined timer window (eg. when the schedule cannot be expressed by systemd timer syntax and is effectively gated by snap run).

43

Can you describe this use case more fully? I still don’t see a full use case where you need to be able to differentiate between different sockets associated with a single service. To me, it seems like if you do need this you should have different services, no?

44

you could have a tcp socket you only want enabled when the service is properly secured, for example.

45

Let’s call socket/timer units “activator” units, of which a service can have multiple.

  • where all the activator units are in the same state, Startup and Current talk about the these units; in Notes, we add a socket-activated or timer-activated (or both), and if the main service is actually running, e.g. socket-activated,running.
  • if the activator units aren’t in the same state, but at least one of them is enabled/active, the Startup/Current column talks about that unit, and say x-activated[,running],see-verbose, with --verbose being a new thing that outputs a more hierarchical and detailed description (you could even include mount units here if appropriate). If the unit that is enabled is not the unit that is active, then flag that somehow also (but also point to --verbose).

this should cover the ~main use case still within snap services, and guide users to find out more.

One thing we could do to simplify formatting of --verbose (or whatever we call it) is only allow a single thing there, instead of the more generous snap services input. Maybe snap services --detailed-service=lxd.daemon or something.

46

Let’s see how that could look like:

$ snap services
Service                                       Startup   Current   Notes
lxd.activate                                  enabled   inactive  -
lxd.daemon                                    enabled   active    socket-activated,running
owner-of.many-sockets                         enabled   active    socket-activated,see-verbose
test-snapd-timer-service.random-timer         disabled  inactive  timer-activated
test-snapd-timer-service.regular-timer        enabled   active    timer-activated,running

And the detailed/verbose output:

$ snap services --verbose owner-of.many-sockets
Service                                       Startup   Current
owner-of.many-sockets.one                     enabled   active
owner-of.many-sockets.two                     enabled   inactive
owner-of.many-sockets.three                   disabled  inactive

Where one, two, three, would be the socket names.

47

We have had some recent feedback that the behavior of the snap start|restart|stop <snap> variants is not always what is expected, especially in the presence of disabled services: https://bugs.launchpad.net/snapd/+bug/1803212

especially the fact that snap restart <snap> now starts not running disabled services as well can be considered unexpected and problematic. We are considering this different set of behaviors:

  • snap stop SNAP should stop all the running services of the snap

  • snap restart SNAP would restart all the running services of the snap (even if disabled) but not disabled and not running ones. This is a change from current behavior also because it means a failed service would not be restarted by this, one would need to use the service-specific variant for that.

  • snap start SNAP would start all the enabled services of the snap. Right now it starts all services.

We could move to this behavior if nothing is deeply relying on the fine points of the current behavior (and introduce possibly flags to get the current behavior). If changing the current behavior along these lines causes real breakage we would have to instead offer a set of flags to get this new behavior.

We are interested on feedback on this?

48

I think the case for an “enabled and not running” service not being started with snap restart SNAP is wrong. I think failed services should be started, and also what about oneshot daemons? I think that oneshot daemons should also be started with snap restart, but only if the oneshot is enabled.

On a related note, is there a way to distinguish between a “succeeded” and “failed” oneshot daemon? The snap services output doesn’t seem provide any way to do so.

1 Like