Increasing Max Locked Memory

HugeKozaky · October 16, 2025, 1:39pm

First of all: Hello!!!, (Skip to the 2nd paragraph if you are in a hurry for the primary topic). This is my first post in this forum. And I must say I love OpenMandriva. I have tried to switch to Linux in the past but most attempts simply ended in dual booting that then turned into just choosing Windows each time. Finally, the 21st of September 2024, my disdain for Microsoft products simply overpowered my laziness and decided to go all in. No more dual booting, no looking back. I was already very into software that was not tied to windows (Blender, Gimp, Inkscape, Audacity, Android Studio, etc), so I decided it was time. I spent some months on Linux mint, which to its credit, eased me into this transition, but I just don’t trust big corporate backed things anymore, so the 24th of June 2025 I decided to move to OpenMandriva. And I must say I am here to stay.

Transitioning to the main topic here: Professional Audio Software is one of the things I was scared to lose in my OS transitions, but audio is just a hobby for me so I was willing to take a hit on that front. I was a bit hopeful since my audio software was Sonar X3 which is tied to my Steam account, and I have heard that steam in particular has come a LONG way when it comes to compatibility. Long story short: It didn’t work, I searched for a native replacement, found one, and installed it: Ardour 8. And here is where the meat of this post comes in: Ardour kept warning me about a “Max Locked Memory” limit, which confused me initially because no other software or game had complained about that before, but then I checked and it was true:

$ ulimit -a

Result:

real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62817
max locked memory (kbytes, -l) 8192 <-------------------------------
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 62817
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

I didn’t want my first post in this forum to be a dumb question, so I searched a bit and found this:

https://forum.openmandriva.org/t/how-to-increase-ulimit/

Problem: This didn’t work for him or me. He went for a workaround there.

So I started searching solutions for other distros and putting together a few different ideas. I couldn’t find an exact match of what I wanted so I ended up doing this:

Go to: /etc/systemd/

$ cd /etc/systemd/

there you can “ls” and see that this place has also multiple “conf” files including “user.conf” and “system.conf”. Modifying this files directly is very frowned upon, based on my research, so I didn’t change them, BUT I used them as reference to make the change I needed to make.

Open “user.conf”

$ nano user.conf

You will see a lot of commented lines marked with a “#” under the “[Manager]” section. If you look carefully there you can see what I was looking for:

#DefaultLimitMEMLOCK=

Following the structure of that file I determined that this is what I needed to do:

1- Exit nano
2- Create this folder if it does not exist: (on /etc/systemd)

$ sudo mkdir system.conf.d

3- go into that folder:

$ cd /etc/systemd/system.conf.d

4- Create “limits.conf” right there

$ sudo nano limits.conf

5- Paste the following content in that file:

[Manager]
DefaultLimitMEMLOCK=infinity

6- RESTART, do not simply logoff. Full restart.

7- Once you are back up. Check if we have actually succeeded with:

$ ulimit -a

The result should be something like this:

real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62817
max locked memory (kbytes, -l) unlimited <---------------------------
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 62817
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

And that’s it! The warnings about locked memory were gone!

However, unfortunately, I must ask a question anyway: I feel like I have Dunning–Krugered my way into something I should not have done despite the fact that it in fact does WHAT I WANTED. Is it safe to leave it like this? In which case. THANK YOU. Problem solved. Or do you guys have a better, safer solution? Sorry for the long post but I wanted you to know exactly what I did and why in case it helps you to help me. Thank you for your time!

Requirements:

I have Searched the forum for my issue and found nothing related or helpful
I have checked the Resources category (Resources Index)
I have reviewed the Wiki for relevant information
I have read the the Release Notes and Errata

OpenMandriva Lx version:

NAME=“OpenMandriva Lx”
VERSION=“6.0 (Vanadium) Rock”
ID=“openmandriva”
VERSION_ID=“6.0”
PRETTY_NAME=“OpenMandriva Lx 6.0 (Vanadium) Rock”
BUILD_ID=“20250420.02”
VERSION_CODENAME=“vanadium”
ANSI_COLOR=“1;43”
LOGO=“openmandriva”
CPE_NAME=“cpe:/o:openmandriva:openmandriva_lx:6.0”
HOME_URL=“http://openmandriva.org/”
BUG_REPORT_URL=“ GitHub · Where software is built ”
SUPPORT_URL=“https://forum.openmandriva.org”
PRIVACY_POLICY_URL=“ Terms of service - OpenMandriva ”

Desktop environment (KDE, LXQT…):

KDE PLASMA

Description of the issue (screenshots if relevant):

Some heavy software (like Ardour) shows warnings about the Max Locked Memory limit being too low.

richp · October 16, 2025, 2:50pm

Hello and welcome I had this problem setting up a pc for my son but it was on debian.

I found this solution for dnf based os’s using pipwire, so i think this should work but make a backup of the limits.conf incase.

mv /etc/security/limits.conf /etc/secyrity/limits.conf.bak

after this make the changes

sudo nano /etc/security/limits.conf

add this to the bottom of the file

yourusername hard memlock unlimited
yourusername soft memlock unlimited
yourusername hard rss unlimited
yourusername soft rss unlimited
yourusername hard as unlimited
yourusername soft as unlimited

ctlr+o enter to save and then ctrl+x enter to exit

Log out and log in should do the trick, this solution is on a per user basis and not system wide, maybe wait for others to chime in as i don’t know if that woud be better or not.

SomeDudeInAZ · October 16, 2025, 5:14pm

This, most assuredly, is the exact opposite of a “dumb question”.

Signed,
Dude
Master of Dumb, Stupid, & Stupidly Obvious Questions

HugeKozaky · October 17, 2025, 2:00am

Thank you for replying! Here is the thing: Your solution is the one you find when digging around. In fact this is basically very similar to the discussion some other users had on this very forum. I just tried your steps, it does not really work for me.

The first red flag is the fact that I DO NOT HAVE a limits.conf on /etc/security

I created the file in 2 locations.

1- /etc/security/

2- /etc/security/limits.d

With the content you posted (replacing “yourusername “ of course )

yourusername hard memlock unlimited
yourusername soft memlock unlimited
yourusername hard rss unlimited
yourusername soft rss unlimited
yourusername hard as unlimited
yourusername soft as unlimited

I read some other files there and I also tried it this way:

@yourusername hard memlock unlimited
@yourusername soft memlock unlimited
@yourusername hard rss unlimited
@yourusername soft rss unlimited
@yourusername hard as unlimited
@yourusername soft as unlimited

In both cases ulimit -a gives me the default 8192KB Limit

However I need to report an interesting discovery:

Something I installed related to Pipewire seemed to have tried your solution before I did.

This file:

/etc/security/limits.d/25-pw-rlimits.conf

Contains this:

# This file was installed by PipeWire project for its libpipewire-module-rt.so

# It is up to the distribution/user to create the @pipewire group and to add the
# relevant users to the group.
#
# PipeWire will fall back to the RTKit DBus service when the user is not able to
# acquire RT priorities with rlimits.
#
# If the group is not automatically created, the match rule will never be true
# and this file will have no effect.
#
@pipewire   - rtprio  95
@pipewire   - nice    -19
@pipewire   - memlock 4194304

The comments are more interesting than the file itself there, but more on that later…

There is also a “99-audio.conf” containing:

@audio - rtprio 99
@audio - memlock unlimited

For a split second there, I was like… Wait a second what if this files ARE WORKING but I just can’t see it because these two user groups don’t exist or because my user is not a member of either? (As referenced in the pipewire commented section)

Welp… Someone correct me if i am wrong but, I tried this:

$ getent group | grep audio:

And the result was this (edited for safety):

audio:x:81:myUserName

So the audio group exists and I am part of it. I also tried this:

$ getent group | grep pipewire:

And the result was this (edited for safety):

pipewire:x:990:myUserName

So the pipewire group also exists and I am also a member of it.

Conclusion: Even some of the system files are telling me that your solution SHOULD work, but it does not. interesting… Maybe someone more experienced will tell us if my deduction is incorrect.

Thank you for your input

iamfraggle · October 22, 2025, 12:14am

So by making the following change in /etc/pam.d/system-auth

- session     required      pam_limits.so
+ session     required      pam_limits.so debug

It adds messages during a restart that you can read back using journalctl:

[fraggle@cotterlin ~]$ journalctl | grep pam_limits
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): reading settings from '/usr/share/security/limits.conf'
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): reading settings from '/etc/security/limits.d/10-gamemode.conf'
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): checking if fraggle is in group gamemode
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): reading settings from '/etc/security/limits.d/25-pw-rlimits.conf'
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): checking if fraggle is in group pipewire
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing - rtprio 95 for GROUP
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): checking if fraggle is in group pipewire
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing - nice -19 for GROUP
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): checking if fraggle is in group pipewire
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing - memlock 4194304 for GROUP
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): reading settings from '/etc/security/limits.d/30-fraggle.conf'
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing hard memlock unlimited for USER
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing soft memlock unlimited for USER
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing hard rss unlimited for USER
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing soft rss unlimited for USER
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing hard as unlimited for USER
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing soft as unlimited for USER
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): reading settings from '/etc/security/limits.d/99-audio.conf'
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): checking if fraggle is in group audio
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing - rtprio 99 for GROUP
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): checking if fraggle is in group audio
Oct 22 01:05:24 cotterlin sddm-helper[1386]: pam_limits(sddm:session): process_limit: processing - memlock unlimited for GROUP

Note that the 30-fraggle.conf mentioned is a file I added to /etc/security/limits.d using the settings suggested by @richp.

What I take from this is that the settings are being correctly interpreted and applied by pam_limits.so and it must be something else intervening that overrides them.

HugeKozaky · October 22, 2025, 4:33pm

Thank you for your reply!
You seem to be 100% correct. The settings in the files are getting processed, and according to the log, presumably applied correctly.

I learned a lot of things here, directly and indirectly from your post:

1- There is a file in /usr/share/security/limits.conf that seems to be a replacement for the file that should be in /etc/security/limits.conf
2- Any files in /etc/security/limits.d are read in alphabetical order and override ANY settings contained in /usr/share/security/limits.conf
3- The correct syntax for these settings is the one provided by @richp, but here it is in more detail:

DOMAIN TYPE ITEM VALUE

yourusername hard memlock unlimited
@yourGroupName hard memlock unlimited

DOMAIN can be either a user or a group (also * or % read /usr/share/security/limits.conf for more details on that).

The TYPE can be hard, soft or -.

The ITEM can be a large variety of things. If you really want to know about it, do this:

cat /usr/share/security/limits.conf

VALUE can be unlimited or any number.

4- I created a file named /etc/security/limits.d/99-ardour.conf and inside I wrote this:

username hard memlock unlimited

Learning from you I edited /etc/pam.d/system-auth

sudo nano /etc/pam.d/system-auth

and I changed this line:

session required pam_limits.so

To this:

session required pam_limits.so debug

Restarted, and then:

journalctl -S 2025-10-22 | grep pam_limits

(Replace 2025-10-22 with whatever appropriate date if you want to test)

And there it was:

oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): reading settings from ‘/etc/security/limits.d/99-ardour.conf’
oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): process_limit: processing hard memlock unlimited for USER
oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): reading settings from ‘/etc/security/limits.d/99-audio.conf’
oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): checking if username is in group audio
oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): process_limit: processing - rtprio 99 for GROUP
oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): checking if username is in group audio
oct 22 11:00:18 NAME_OF_PC sddm-helper[1248]: pam_limits(sddm:session): process_limit: processing - memlock unlimited for GROUP

So, just as you say, apparently IT IS WORKING, but somewhere after that, these settings seem to be discarded or overwritten somehow because if you do this:

ulimit -a

You continue to get this:

max locked memory (kbytes, -l) 8192

Unless you apply the solution I provided on the opening post.

So yes, I think your theory is correct. The commented text in /usr/share/security/limits.conf points to the fact that there is a file hierarchy, in which the last config file has the last word. It is explicitly stated that the files in /etc/security/system.d will override the settings in /usr/share/security/limits.conf :

1- /usr/share/security/limits.conf
2- /etc/security/limits.d/*.conf
3- Somehow memlock gets set to 8192KB overriding any previous settings.

The only thing that seems to override #3 is this:
4- /etc/systemd/system.conf.d/*.conf

I am assuming number 4 happens after, because it sticks. But instead of being user, group or a service based solution it is a system wide solution, that maybe is unsafe? Hence the reason we are here.

Thanks for the input!!!

HugeKozaky · October 23, 2025, 4:04pm

Small Update: Maybe I should edit the original post to add this. You guys let me know if that is the way to go. But… Here is the update:

My original solution is working on top of /etc/systemd/system.conf by dropping a config file on /etc/systemd/system.conf.d/ In this particular case I named the file limits.conf.

That is potentially a system wide unsafe solution. Hence this thread. Some theories have formed since then about the order some things happen and why other, quite frankly, better looking and safer looking solutions just don’t work. Piggybacking on @iamfraggle ‘s theory, I theorized that my solution must happen last since is the only one that sticks. I feel less sure about that today. And here is why:

/etc/systemd/system.conf is not the only systemd file that contains what I need:

[Manager]
#DefaultLimitMEMLOCK=

/etc/systemd/user.conf also has that. So I had this thought: “Maybe if I drop my change on top of the user.conf instead, the change is going to be USER wide and that should be better/safer? Right?”

I tried this:

sudo mkdir /etc/systemd/user.conf.d

And dropped a limts.conf there with:

[Manager]
DefaultLimitMEMLOCK=infinity

Then used:

systemd-analyze cat-config /etc/systemd/user.conf

That let’s you see if the file you dropped is being properly recognized, and it was, because you could see my file and the settings referenced in the results.

# /etc/systemd/user.conf.d/limits.conf
[Manager]
DefaultLimitMEMLOCK=infinity

Weidly enough though, THIS DOES NOT WORK.

ulimit -a

Back to 8192KB:

max locked memory (kbytes, -l) 8192

The only thing that works is the original solution: Dropping the config over /etc/systemd/system.conf (in my case placing my limits.conf in /etc/systemd/sytem.conf.d/). I don’t know what this means. The only thing that comes to mind here is that this setting seems to resist any change at the user or group level. Only a system level change seems to work. Why?

SomeDudeInAZ · October 24, 2025, 12:27am

Glad it works. What you might want to try is asking this again over on the “Level 1 Techs” or “Serve The Home” forums. Probably Level 1.

That’s an amazing place too.

iamfraggle · October 25, 2025, 3:03pm

So I’ve discovered something very interesting. It turns out that whatever is doing the override only happens when logging in via the GUI.

If you open another TTY and do a non-GUI login, ulimits -a on that session shows that the max memlock has indeed been increased to unlimited!

iamfraggle · October 25, 2025, 6:39pm

I’ve found that the key difference between the two sessions is that the console-only session has a login process as its parent, while it appears that any process created under the GUI session has a systemd --user process as its parent.

Running prlimit -p <PID> shows that while the login process has unlimited memlock, the systemd --user process has 8MB memlock.

It’s unclear when the user systemd process gets created. It already exists by the time the GUI login screen appears, which is odd because I haven’t logged in yet…

In any case my theory is that because the systemd process has limited memlock, any process based off it has limited memlock.

Looking at /etc/pam.d/systemd-user there is no entry for pam_limits.so, so I added one just before the last one for pam_systemd.so

session  optional   pam_umask.so silent
session  optional   pam_limits.so  # I added this line
session  optional   pam_systemd.so

One restart later, open Konsole and voila:

[fraggle@cotterlin ~]$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 39
file size                   (blocks, -f) unlimited
pending signals                     (-i) 256003
max locked memory           (kbytes, -l) unlimited
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 99
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 256003
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited
[fraggle@cotterlin ~]$ pstree -s -p $$
systemd(1)───systemd(1447)───konsole(5488)───bash(5507)───pstree(5705)
[fraggle@cotterlin ~]$ prlimit -p 1447
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
AS         address space limit                unlimited unlimited bytes
CORE       max core file size                 unlimited unlimited bytes
CPU        CPU time                           unlimited unlimited seconds
DATA       max data size                      unlimited unlimited bytes
FSIZE      max file size                      unlimited unlimited bytes
LOCKS      max number of file locks held      unlimited unlimited locks
MEMLOCK    max locked-in-memory address space unlimited unlimited bytes
MSGQUEUE   max bytes in POSIX mqueues            819200    819200 bytes
NICE       max nice prio allowed to raise            39        39 
NOFILE     max number of open files              524288    524288 files
NPROC      max number of processes               256003    256003 processes
RSS        max resident set size              unlimited unlimited bytes
RTPRIO     max real-time priority                    99        99 
RTTIME     timeout for real-time tasks        unlimited unlimited microsecs
SIGPENDING max number of pending signals         256003    256003 signals
STACK      max stack size                       8388608 unlimited bytes

and now the program I was trying to run that was complaining about the memlock limit no longer is.

This seems a slightly better solution than changing system.conf as this allows making changes by user/group rather than a blanket system-wide limit change.

HugeKozaky · October 26, 2025, 2:25pm

Thank you for your reply! If I couldn’t get a satisfactory solution in here I was probably gonna have to ask somewhere else, but thankfully I think that won’t be necessary now .

HugeKozaky · October 26, 2025, 3:10pm

WOW! Thank you very much! THIS IS THE SOLUTION. It makes everything in /etc/security/limits.d work as it should!

I tested this: (on: /etc/security/limits.d/99-ardour.conf)

username hard memlock unlimited

And it works!

Also, I tried this: (on: /etc/security/limits.d/99-audio.conf)

@audio - rtprio 99
@audio - memlock unlimited

And that also works! Essentially adding one of the files I just mentioned and adding the middle line:

session optional pam_umask.so silent
session optional pam_limits.so # ADDED LINE
session optional pam_systemd.so

To the /etc/pam.d/sytemd-user file as you suggested solves this problem!

Thank you very much @iamfraggle !!!

I must say, when you mentioned systemd --user and login I stopped reading for a little bit just to later return and see this:

$ pstree -s -p $$

Which killed me. I was out here like a caveman hitting CTRL+ALT+F3 and typing:

$ ps -axjf | more

To see where was my “ps” command under, when there was, literally, the perfect 1 line response command to know exactly the PID to check with this:

$ prlimit -p <PID>

If I could inconvenience you just a tad more here, let me ask you this:

How do you come to: What if different sessions have different “root” processes and that might be a clue for this issue? What trigger that thought? (Besides being very experienced perhaps),

Thank you again. You solved the thread!

SomeDudeInAZ · October 26, 2025, 5:03pm

I’m going to second that @iamfraggle . What made you think to check directly at the TTY?

And you did this going into the tty after logging in to the regular session? Not going direct to tty from grub?

I am officially adding this trick to my toolbox.

Also I wonder if this will solve one of my many annoyances - the fact that gui programs often don’t respect user and group sticky-bits on directories.

SomeDudeInAZ · October 27, 2025, 4:44am

For the sake of completeness I just found a section on ulimit in the Bash Reference Manual by Chet Ramey (page 96)

Main Page: GNU Bash manual - GNU Project - Free Software Foundation

Download link: https://www.gnu.org/software/bash/manual/bash.pdf

iamfraggle · October 27, 2025, 7:35pm

Some forum discussion that my searching turned up had a throwaway comment that said you should try any PAM config changes via a separate TTY as a sanity check before a reset or logout so you don’t lock yourself out of the system. (That advice actually saved me a couple of times as well!)

Correct.