You are not logged in.
Hi all,
After an upgrade today, firefox refuses to start with error:
os_mmap failed.: Cannot allocate memory
chromium also doesn't start, but there the error is:
zsh: trace trap (core dumped) chromium
These problems started after a pacman -Syu failed midway because of a problem upgrading mercurial. I tried reinstalling all packages using "pacman -Qqn | pacman -S -", but the problem persists even after successful completion of that command.
Any ideas on how to solve this, please?
Last edited by bart_janssens (2022-06-22 20:24:08)
Offline
Update: there is an actual memory limit problem, running gdb on chromium also shows a memory allocation error, and allocating an 8 GB array in Julia fails (on my 16 GB machine).
ulimit -a shows a value of 8388608 kbytes for address space. When starting an LXDE session the ulimit is not set and firefox starts fine, so I'm wondering if this is something introduced in plasma 5.25? I can't find any setting related to ulimit, and the problem exists even when creating a new user, so it's not something in my personal account settings.
Offline
No idea what plasma does there, but can you unset the limit w/ a shell script in ~/.config/plasma-workspace/env/
Also what's your user shell? (plasma and LXDE might differ in which shell they use to setup the session, the user shell or simply /bin/sh)
Offline
No idea what plasma does there, but can you unset the limit w/ a shell script in ~/.config/plasma-workspace/env/
Unfortunately that doesn't work, the ulimit can't be unset once it is set (or at least I can't figure it out, I placed "ulimit -Sv unlimited" in a script). I also configured plasma to start using startx (normally I use sddm), same problem.
Also what's your user shell? (plasma and LXDE might differ in which shell they use to setup the session, the user shell or simply /bin/sh)
Mine is zsh, the test user I created has bash, both give the same problem.
Having tried several alternative desktops now, I can only reaffirm my commitment to sticking with KDE, but I am at a loss
Offline
Is the hard limit also affected?
Can you successfully "ulimit -a unlimited" in an interactive shell (and start FF from there)?
Can you "prlimit -v unlimited $(pidof plasmashell) # processname is a guess"?
Edit:
cat /etc/pam.d/kde
Last edited by seth (2022-06-21 21:48:20)
Offline
In an act of desperation, I downgraded my system to the packages from 14th of June (Plasma 5.24) and everything works again. So this really looks like some behavior introduced in Plasma 5.25 now.
Offline
Is the hard limit also affected?
Can you successfully "ulimit -a unlimited" in an interactive shell (and start FF from there)?
No, using ulimit in an interactive shell has no effect. I read somewhere that increasing the limit once it is set is not possible (ulimit man page I think)?
Can you "prlimit -v unlimited $(pidof plasmashell) # processname is a guess"?
This gave me a good hint to check. This is startplasma-x11:
sandy ~ % prlimit --pid 3030
RESOURCE DESCRIPTION SOFT HARD UNITS
AS address space limit unlimited unlimited bytes
And this is plasmashell:
sandy ~ % prlimit --pid 3107
RESOURCE DESCRIPTION SOFT HARD UNITS
AS address space limit 8589934592 8589934592 bytes
After this command:
sudo prlimit --as=unlimited --pid 3107
I can start a new terminal and run firefox, but the removal of the limit requires sudo.
The contents of /etc/pam.d/kde:
#%PAM-1.0
auth include system-login
account include system-login
password include system-login
session include system-login
Note: I didn't see your message before the downgrade, so I upgraded again (without error this time), confirming 100% that this issue appeared just by upgrading.
Offline
but the removal of the limit requires sudo
Because of the hard limit.
The KDE pam is unfortunately not the source (there's a pam_limits module)
/usr/bin/startplasma-x11 is a shell script? I'd look there.
Offline
/usr/bin/startplasma-x11 is a shell script? I'd look there.
Unfortunately it's a binary. I even did some grepping on the Plasma source, but couldn't find anything.
Offline
Just a hunch…
systemctl --user show plasma-core.target plasma-plasmashell.service plasma-workspace-x11.target plasma-workspace.target | grep -iE (memory|limit)
Offline
Just a hunch…
systemctl --user show plasma-core.target plasma-plasmashell.service plasma-workspace-x11.target plasma-workspace.target | grep -iE (memory|limit)
Thanks, that was the golden tip!
Result after narrowing down a little:
% systemctl --user show plasma-plasmashell.service | grep LimitAS
LimitAS=8589934592
LimitASSoft=8589934592
As it turns out, /etc/systemd/user.conf (modification date 2018, I don't remember if I did that) had "DefaultLimitAS=8G". Commenting this out fixed the problem. I see in the Plasma changelog at https://kde.org/announcements/changelog … .5-5.25.0/ "Enable systemd boot by default.", so I guess that may be why this only came up now.
Thanks for the help!
Offline