Snap memory quota are ignored by some snap packages

snapd
1

Hello,

I tried to limit the memory usage of both firefox and chromium snap using the following commands:

snap set-quota memlimit-chromium --memory=4GB chromium

snap set-quota memlimit-firefox --memory=4GB firefox

However, even after restarting chrome of firefox, quotas don’t seem to be enforced:

~ $ snap quotas
Quota              Parent  Constraints    Current
memlimit-chromium          memory=4.00GB  
memlimit-firefox           memory=4.00GB  

~ $ snap quota memlimit-firefox
name:  memlimit-firefox
constraints:
  memory:  4.00GB
current:
  memory:  0B
snaps:
  - firefox

~ $ ps -ef | grep -c -E "firefox"
10

~ $ ps -ef | grep -c -E "chrome"
26

i use snap on ubuntu 23.04.

~ $ snap version
snap    2.59.5
snapd   2.59.5
series  16
ubuntu  23.04
kernel  6.2.0-25-generic

~ $ snap list | grep -E "firefox|chromium"
chromium                        114.0.5735.198              2529   latest/stable  canonical**     -
firefox                         115.0b9-1                   2825   latest/beta    mozilla**       -

i followed this documentation:
https://snapcraft.io/docs/installing-snap-on-ubuntu

and did not find any related issue on:
https://bugs.launchpad.net/snapd

I did set experimental.quota-groups to true before upgrading to ubuntu 23.04 and did not modify this setting (but from snapd release notes this should not be necessary anymore)

~ $ sudo snap get system experimental.quota-groups
true

Did i miss something ? Cheers,

2

Not that it changes anything, but you’re not alone !

I have the same experience with Firefox. I was aware the quota groups were experimental so I waited until now (23.10), but turns out it either plain doesn’t work, or seems not to work. Did you try setting a ridiculously low amount to see how it fares ? I’m going to do that and come back.

For the record, I had been confidently limiting the Resident Set Size (i.e. non-swapped RAM usage) for YEARS, until I discovered the limit wasn’t enforced any more since kernel… 2.4.30 ! I started to put a limit after I got a bad experience with Firefox on Windows, where a maliciously designed web page took all available RAM. I was able to enforce this on Windows using the Job Objects, tested and working, but set the limit on Linux without testing… Limiting the Addressing Space to 4 GiB prevents FF from starting for some mysterious reason, maybe snap related.

EDIT : I’m back, and didn’t have to check by setting the memory limit to a very low value. The Snapcraft docs specify that resource quotas apply to snap services only, hence it doesn’t apply to simple apps. Adding a snap to a quota group means that resource quotas will be applied to all snap services within that snap.

Let’s take the firefox snap as an example. It contains two programs : firefox and geckodriver, neither of which is a service. Trying to add firefox.firefox or firefox.geckodriver to the quota group results in an error stating that they’re not services.

While the web documentation is relatively clear on that point, the inline help (snap help set-quota) is much more ambiguous if not misleading.

So in the end, we’re still on our own if we want to enforce resource limits. Fwiw, I’m back to good old setrlimit(), which can be used with the bash primitive ulimit. I decided to limit the data segment size to 4 GiB : ulimit -d 4194304 in an open shell window, and the limit is applied to everything that’s started from there.

You can limit virtual address space instead (ulimit -v), but I found that FF doesn’t start properly and hangs, if the value is too much under 16 GiB, which is my total RAM. If you set it to your system’s total amount of RAM it will probably work, but you may find that value is a tad too much.

… or you can use cgroups. That’s what the snap system uses (cgroups v2), but for services only. I’m not very familiar with cgroups yet, but will probably end up using it at some point, out of curiosity at least.

1 Like
3

Hi, thanks the pointers, and sorry for the late reply.

I confess i only looked to the cli doc, and i confirm, they were misleading.

I am quite familiar with cgroups and while i did not mentioned it in the original post but i did try to use cgroups to limit firefox ram, it did not work. If i remember correctly (it was almost a year ago), here are the issues i had:

  • Placing the firefox snap inside a cgroup did not work as it was already a child of the snapd cgroup.
  • Modifying the cgroup setting setup by snapd for firefox did not work as snapd kept reappling its settings.

I do prefer using cgroups over setrlimit, and in the end not being able to properly manage ram usage on my desktop is what brought me back to debian for my desktop usage.

Kind regards,

4

As the previous post referenced, the memory quotas are only available for services. Snap services have a permanent systemd unit file describing the service, where those limits are set and applied by systemd. Any user applications are only started in a transient units, and snapd is not passing any parameters to those.

I suppose you could however try to apply the limit manually. The apps are placed in a per instance cgroup within your user session hierarchy, the name will look like this /user.slice/user-<uid>.slice/user@<uid>.service/app.slice/snap.ohmygiraffe.ohmygiraffe-<random-uuid>.scope (just an example for ohmygiraffe snap). Systemd user session daemon should set up the directories such that they are writable for you, and you’re can manipulate memory.* properties.