1

I have set ulimit in /etc/security/limits.conf. When I log in into my desktop environment as user testuser normally (using slim login manager), everything works fine.

When I log in as user testuser via Xephyr (from my other session as another user), everything works fine except chromium browser. This is the error I get in dmesg:

Chrome_ChildIOT (2472): VmData 4310827008 exceed data ulimit 4294967296. Update limits or use boot option ignore_rlimit_data.

And chromium is unusable (it starts, but waits indefinitely to load any page)

All other programs except chromium have correct limits set. I have verified this using:

find /proc/ -maxdepth 1 -user testuser -exec cat {}/limits \; | grep 'Max data size'

all PIDs have Max data size set to unlimited:

Max data size             unlimited            unlimited            bytes

except chromium processes:

Max data size             4294967296           4294967296           bytes     
Max data size             17179869184          17179869184          bytes     
Max data size             17179869184          17179869184          bytes     
Max data size             17179869184          17179869184          bytes     
Max data size             17179869184          17179869184          bytes     
Max data size             17179869184          17179869184          bytes     
Max data size             17179869184          17179869184          bytes     
Max data size             17179869184          17179869184          bytes  

I would like to understand:

1) why does chromium have different limits than all other programs ?

2) where do the "default" limits come from (where does chromium take the limit 4294967296 from ?

3) how can I change these default limits once and for all, globally, for all processes regardless whether they use pam or not ?

  • you are dealing with computers ... use binary or hexadecimal notation instead of decimal notation .... some of your questions may be answered – jsotola Jan 3 at 8:27
  • 1
    @jsotola What are you talking about? – cutrightjm Jan 7 at 2:45
  • your question #2 ... instead of looking at default limit as decimal 4294967296, look at the value as hexadecimal – jsotola Jan 7 at 3:08
  • You say "I have set ulimit in /etc/security/limits.conf", but make no further mention of it. What did you set it to? – ctrl-alt-delor Jan 7 at 22:52
5
+200

1) Why does chromium have different limits than all other programs ?

Chromium may look like a simple application but it is not, first there is the multi-threading which makes chromium run multiple process for different tasks (extensions, tab, core web-engine, etc) then the virtualisation, chromium use many sandbox to isolate the browsing activities which make it use more ressource than other application, also the used web-engine is not a light one... add to that the different needed libraries that are required to run and other heavy ressources functions... some related documentations are available here, here and this article have some useful infos

2) Where do the "default" limits come from (where does chromium take the limit 4294967296 from ?

4294967296 bytes (4096 MB, or 4GB limit) chromium have by design a 4GB limit this is hard coded, more infos about this available here and here

3) how can I change these default limits once and for all, globally, for all processes regardless whether they use pam or not ?

Not an easy task but you are doing it right for most usual process, now for complicated process like chromium you need to customize your config for each "special" app.

For chromium there are some command parameters that can be used to customise/enable/disable features, you can try to use some of them to make chromium suit your needs, here are some interesting switch:

Those switch can be used with a command line like this /usr/bin/chromium --single-process

--single-process
--aggressive-tab-discard
--aggressive-cache-discard
--ui-compositor-memory-limit-when-visible-mb
--disk-cache-dir  # Use a specific disk cache location, rather than one derived from the UserDatadir.
--disk-cache-size  # Forces the maximum disk space to be used by the disk cache, in bytes.
--force-gpu-mem-available-mb  # Sets the total amount of memory that may be allocated for GPU resources
--gpu-program-cache-size-kb  # Sets the maximum size of the in-memory gpu program cache, in kb
--mem-pressure-system-reserved-kb  # Some platforms typically have very little 'free' memory, but plenty is available in buffers+cached. For such platforms, configure this amount as the portion of buffers+cached memory that should be treated as unavailable. If this switch is not used, a simple pressure heuristic based purely on free memory will be used.
--renderer-process-limit  # Overrides the default/calculated limit to the number of renderer processes. Very high values for this setting can lead to high memory/resource usage or instability.

You can also run chromium with a script that update the ulimit for it

ulimit -Sv 43520000 #4.2GB
/usr/bin/chromium
1

I ran into the same problem with Chrome, usually when streaming TV channels. Your error message provides the answer for you:

Add ignore_rlimit_data to the GRUB_CMDLINE_LINUX_DEFAULT entry in /etc/default/grub. Update grub, then reboot.

  • that seems like a dirty hack, and not addressing the underlying cause. – 400 the Cat Jan 7 at 4:34
  • I wouldn't consider it a hack - it is mentioned as a solution in the error message - but I agree that is does seem to mask the cause as opposed to directly addressing it. It works for me, so I never did any more research. – ajgringo619 Jan 7 at 4:39
  • so what exactly is the effect of booting with ignore_rlimit_data kernel boot option ? When I try it, the ulimit values are unchanged, chromium still shows the same values as before. Although it does not complain anymore and it works fine. – 400 the Cat Jan 7 at 5:13
  • in other words: is this solving the problem, or just masking the symptoms ? – 400 the Cat Jan 7 at 5:14
  • I found a few references to this problem, going back at least 4 years, but there doesn't seem to be a consensus fix or reason why it's still happening. – ajgringo619 Jan 7 at 17:36
1

On a modern 64bit system there is no sane reason to limit VM space.

VM space is used for anything memory mapped, not just physical memory. The most common usage of exhorberant amounts of VM data in current computing is sparse buffers, where a file or database that has only a fraction of it in physical memory, has the entire thing in virtual memory, with a routine to load it transparently as needed.

You want to limit PHYSICAL data memory use, and even there you should use the settings in /sys and/or /proc/sys to do so, not ulimit, as this properly signals the program that it's low on memory instead of just faulting.

Honestly, ulimit is a dirty old hack that really isn't much good for anything except for preventing denial of service attacks on a multiuser system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.