It’s acting as if memory.oom.group is set to 1, even though it’s not:
dullbananas:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-codium-158608.scope/memory.oom.group
0
dullbananas:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/memory.oom.group
0
dullbananas:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/memory.oom.group
0
dullbananas:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/memory.oom.group
0
dullbananas:~$ cat /sys/fs/cgroup/user.slice/memory.oom.group
0
dullbananas:~$ cat /sys/fs/cgroup/memory.oom.group
cat: /sys/fs/cgroup/memory.oom.group: No such file or directory
What commands are running in the integrated terminal? Wouldn’t it be better to run it on external ones?
Nice. This is such a stackoverflow answer. I love it
Lol, what make it so?
looks like a question to me
How little ram and swap do you have that this is a problem?
You might just use ulimit: https://unix.stackexchange.com/a/746762/90708
I feel like there’s a better way to do this, unless you’re intentionally trying to run out of RAM.
How do you control the oomkiller? Short answer - You don’t. That’s by design. You can google for the lkml discussions about it.
What you can do is set cgroups around vsc to limit its resource consumption to improve your odds of avoiding the oomkiller’s attention entirely. Google up the cgroups docs for details.
