It is possible to limit a snap’s resources by issuing a command like
sudo systemctl set-property snap.<snapname>.<appname>.service CPUQuota=20% MemoryLimit=100M TasksMax=50
There are many options: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
Can this be exposed via the snapd API so a management service on a host can impose these limits if it has permissions to snapd-control slot?
cc @pedronis
This is a nice idea. Exposing something via the snapd API seems like a reasonable path forward since snapd is in a position to perform any mediations. This particular systemd approach does only work for daemons though (if the implementation details are hidden behind the snapd API, it’s conceivable to implement this as requested as a phase 1…). In fact, it should be possible for snapd to allow the same controls for the snap to limit itself since snapd can determine from which snap the request is coming, processing the request if it matches the requester.
Related, @mvo and I discussed creating a per-snap cpu and memory cgroup and unconditionally[1] adding all of the snap’s processes to them, with snapd not imposing any cpu/memory/tasks policy. This would apply to daemons and non-daemons alike and could be exposed via the snapd API as suggested here (with a different backend implementation).
For anyone implementing this, it would probably also be interesting to see what kinds of gadget snaps tie-ins might be worthwhile since it is conceivable a gadget owner will want to put these controls in place without requiring a management snap (and the gadget owner is in the perfect position to understand how particular snaps should operate on a particular device).
[1] we likely want to actually mimic https://github.com/snapcore/snapd/pull/6494
