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.