since we can control settings values using snap set and retrieve change using snapctl, sometimes it is required to restart the service for changes to take effect. If snapped application does not have this already built in, there is very little one can do, as systemctl is not accessible from within snap.
This could be easily address by extending snapctl to provide start/stop/restart options for applications defined by the snap. Internally this would likely be wired back to systemctl call
While we can define some level of automation here (e.g. define settings values triggering service restart in snapcraft.yaml), it’s important to support manual option first, no matter how we define automatic option there will be always case which will not be addressed…
Today snapctl only supports set/get and that is about configs and plug/slot attributes.
Instead of opening the gates here with a fully generic ability to randomly start stop services with snapctl, we should instead have an automated restart function built into the snapctl backend and provide a mapping of elements (i.e. config variables) to this …
We could. have a separate .yaml file or some config in snap.yaml or snapcraft,yaml where you can bind config/hook elements to automated restarts. So that a “snapctl set foo” will simply automatically restart the defined/mapped service.
This gives far more security control to the backend than randomly allow snapctl full systemctl abilities and thus pretty much full OS control.
There is no way to call snapctl directly today, you can only execute it from a hook (unless that changed recently), so there should always be a binding possible to some of the hook elements. For actual admin interaction we already have “snap start/stop/restart” implemented.
There are different ways to implement this and it is true that we cannot gives snaps access to systemctl without giving them device ownership, but I interpreted @ondra’s request as: allow snaps the ability to restart their own daemons, and this could be exposed via snap/snapctl which will talk to the out-of-process snapd. snapd is then in a position to mediate the requested action against the security label of the process running snapctl/snap (ie, via libapparmor) rather than just passing the options straight through to systemctl.
This idea would work well on all systems that have partial or full apparmor support, but not on systems with no apparmor support (however, on those systems, snaps can simply use systemctl directly, so no practical difference in terms of security today).
We already have service management in “snap” and since snapctl will only operate inside hooks proxied through “snap set/get” i dont see why snapctl itself needs full systemctl capabilities beyond automatically restarting a service if a config option changes via get/set.
Instead of requiring the developer to explicitly add “snapctl stop … process variable change … snapctl start” in the hook it would be way cooler if the service restart happens automagically if the var changes without having the developer to explicitly add such stop start commands.
I agree with @jdstrand here, my understanding of @ondra’s request was the same, i.e. give snaps the ability to control (restart) own services only.
The idea of making this automated based on some mappings may look tempting, but I think it would only work for simple cases and not for more sophisticated scenarios where restarts need to actually be guarded by some logic; therefore I think “manual” control via snapctl is more useful.
@ondra That’s planned and in fact most of the work has landed already with the implementation of snap start/stop/restart.
@pstolowski Do you want to push forward the implementation of the snapctl side? Should be relatively quick since most of the internal details have been nailed already.
@niemeyer I’m happy to take it, but from the conversations we had on IRC earlier this morning it seemed that @chipaca is going to implement exactly this for snapctl side. John, can you clarify?
@pstolowski Right, exactly. As I said above it was already planned and most of the work has landed. @chipaca has quite a few things on his plate, so the point was that if you want to push it forward sooner, that sounds reasonable too.
Naturally, talk to him so we don’t have the same thing done twice.
I believe that “snaps” have a promising future as a clear and easy way of packaging. Unfortunately, at my workstation (Ubuntu 16.04) few snaps work because my user belongs to Active Directory and snaps are unable to communicate with the SSSD service.
After more testing with this, I realise to take full advantage of this feature, can we add also enable and disable options?
I’ve came across snap, with optional service, which should be run based on configuration.
Rather that start stop it from service based on settings, configure hook would be ablate to enable/disable it based on settings?
Also can I even call snapctl stop from service itself, or this is only permitted from configure hook? As with this restriction I’d not be even able to stop service in easy way. Unless calling snapctl set stopme=now and stopping service from configure hook
@ondra The service-related commands in snapctl work from any place inside the snap, not just the configure hook. You can also enable/disable by using the options –enable and –disable for the start and stop commands, respectively.
@niemeyer sweet, that should should address the use case.
I will look more into –enable and –disable for the start and stop commands. it definitely looks like something I want to use more
thanks
Dunno what you mean by “by the daemon” but best way is to control services from configure hook
Here is one example wekan
If you want to control this from another service, you can call snapctl set = which will trigger configure hook where you can start/stop/restart/enable/disable daemons…
