I’d like to have a supervisor service that is able to monitor the health of other snaps and overall system, performing commands as required, such as:
- systemctl daemon-reload
- snap revert app-name
Is it possible for this service to be deployed as a snap or does it have to be deployed as a regular service outside of the snap ecosystem?
I have tried moving this service into a snap but if the snap service tries perform the any of above commands, I get the expected “Running in chroot, ignoring request.” errors.
I have tried adding the core-support plug to my snap, which gets auto-connected on install but still cant perform the above commands. I understand this is probably a feature not a bug, but was wondering if there are any suggestions for my use case.
That sounds a little bit like the core support interface which is reserved for core type snaps
there are the snapd-control (for “snap revert app-name” ) and the shutdown (for “reboot”) interfaces …
if your system uses only snaps the “systemctl daemon-reload” is handled by snapd internally when you install/remove/disable/enable and stop/start a snap (or snap service), which is why there is no interface covering this… do you actually need it ?
core-support is an internal interface, the store wont let any snap except the core snap itself use it (your upload would be blocked)
Thanks for that, I have marked as solved because it answers the general case of how to confine a snap that requires access to rebooting and reverting. However this will not work if the supervisor service is run as a daemon due to the aforementioned “Running in chroot, ignoring request.” issues.
I had a look at systemd and because of the logic there every non-classic snap will fall victim of the “running in chroot” bail-out code. Essentially the
/ of the calling process needs to be the same as
/proc/1/root which will never be the case for snaps.