Hallo!
Ich habe keine Ahnung was Harrison Mixbus ist, aber ich gehe mal von Audio aus. Eigentlich ist dafür unser Forum Audio Mensch @djeli zuständig. 
Da mich das Thema aber trotzdem interessiert woran es liegen könnte, habe ich mal nachgeschaut um was es überhaupt geht.
Also, da Harrison Mixbus meckert, dass dein „locked memory“ zu knapp ist und ulimit -l dir nur mickrige 8192 ausspuckt: Das sind 8192 KiB, also exakt 8.388.608 Bytes (8 MiB, oder ca. 8.4MB ) – und eben nicht 8 GB.
Bevor du jetzt irgendwo blind Werte änderst, lass uns erst mal den Übeltäter suchen und schauen, wo dieser Wert überhaupt herkommt.
1. Check den aktuellen Status
ulimit -l
ulimit -Hl
ulimit -Sl
Wenn hier überall 8192 steht, kleben dein Hard- und Soft-Limit momentan eisern auf diesen 8 MiB fest.
2. Gibt es schon eine memlock-Regel?
Schau mal nach, ob in den Sicherheitskonfigurationen schon was hinterlegt ist:
grep -Rni memlock /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null
Wirf dabei vor allem einen Blick in das Verzeichnis /etc/security/limits.d/.
Falls du dort sowas findest wie…
@realtime - memlock unlimited
…heißt das leider noch nicht, dass es auch für dich gilt. Diese Regel greift nämlich nur, wenn du auch wirklich in der realtime-Gruppe bist.
3. Bist du überhaupt in der richtigen Gruppe?
Das finden wir hiermit heraus:
id
# oder kürzer:
id -nG
Taucht realtime in der Liste nicht auf? Dann füg dich einfach selbst hinzu:
sudo usermod -aG realtime $USER
Wichtig: Danach einmal komplett ab- und wieder anmelden, damit Linux das auch checkt. Danach prüfst du das Limit noch mal mit:
ulimit -l
Wenn dort jetzt unlimited steht: Super, du bist fertig!
4. Immer noch bei 8192? Check PAM!
Falls du schon in der Gruppe warst und es trotzdem nicht klappt, schau nach, ob das entsprechende PAM-Modul überhaupt aktiv ist:
grep -Rni pam_limits /etc/pam.d/
Such hier nach einer Zeile, in der pam_limits.so steht. Wenn die fehlt (oder mit einer Raute # auskommentiert ist), ignoriert das System deine limits.conf.
So aktivierst du es:
Danach einmal komplett ab- und wieder anmelden, damit PAM die Limits beim Login auch wirklich lädt.
5. Der letzte Part der dazwischenfunken kann: systemd (wie immer)
Das prüfen wir so:
systemctl --user show --property=DefaultLimitMEMLOCK
Kommt dabei DefaultLimitMEMLOCK=8388608 heraus? Da haben wir es: 8388608 Bytes = 8192 KiB = 8 MiB
In dem Fall ignoriert das System die klassischen Config-Dateien, weil das Limit vom systemd-User-Manager diktiert wird. Um das zu fixen, legst du eine eigene User-Konfiguration an:
mkdir -p ~/.config/systemd/user.conf.d
nano ~/.config/systemd/user.conf.d/limits.conf
Pack dort einfach diesen Block rein:
[Manager]
DefaultLimitMEMLOCK=infinity
Danach einmal komplett ab- und wieder anmelden (oder den systemd-User-Manager neu starten), damit die Änderungen greifen.
Danach sollte beim erneuten Testen alles passen:
systemctl --user show --property=DefaultLimitMEMLOCK
ulimit -l
Kurz & knapp: Der Schnelldurchlauf
Wenn du das Problem das nächste Mal hast, wirf einfach direkt diese vier Befehle an, um die Lage zu checken:
id
ulimit -l
grep -Rni memlock /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null
systemctl --user show --property=DefaultLimitMEMLOCK
- Steht die
realtime-Regel, bist du aber nicht drin? → Gruppe beitreten.
- Passt bei PAM und den Gruppen alles, aber das Limit klemmt? → systemd-Config anlegen.
