Running Systemd commands inside a snap

snapcraft
#1

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
  • reboot
  • 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.

#2

That sounds a little bit like the core support interface which is reserved for core type snaps

#3

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)

1 Like
#4

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.

1 Like
#5

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.

Opinions?

2 Likes