yes i am in the audio group and i have restarted my laptop after making changes.
so should i change something there too… i dont understand i have done this before too it always worked, i dont what im doing wrong.
the only other place I know limits resources can apply is via systemd settings… and systemd is extremely versatile in this area if your distro is using them.
Are you on Arch Linux? Arch uses the ‘realtime’ group.
On my system there is an application that put a folder in /etc/security/limits.d/ with a txt file that says something like @users memlock 1024. I’m not at my computer right now so I couldn’t say exactly what it is. I commented out that line. Look through any folders that are in /etc/security/limits.d/ for config files that might be changing your memlock settings.
highly unlikely there are any sub-folders in this path, perhaps if you saw something as a “.txt” file then it is just a readme textfile. Configuration files are named “.conf” in this path and wouldn’t get parsed from sub-folders…
Right. Sorry I’m not at the computer. I will look into it when I am at home.
I have pam_limits in a number of files on my Ubuntu 18.04 system:
/etc/pam.d/cron:session required pam_limits.so /etc/pam.d/lightdm:session required pam_limits.so /etc/pam.d/lightdm-autologin:session required pam_limits.so /etc/pam.d/lightdm-greeter:session required pam_limits.so /etc/pam.d/login:session required pam_limits.so /etc/pam.d/runuser:session required pam_limits.so /etc/pam.d/sshd:session required pam_limits.so /etc/pam.d/su:session required pam_limits.so /etc/pam.d/systemd-user:session required pam_limits.so
My guess is that whatever runs your login session isn’t including common-session
its working fine now. i did not do anything just recently updated the system there were some major updates systemd kernel and all its fixed now.
yes i am on arch linux.
I installed the package
realtime-privileges. It adds a file
and adds your user to the ‘realtime’ group. I found for ALSA MIDI you also need to be in the ‘audio’ group. If it’s working it looks like your manual changes worked.
I’ve got a file that appeared in
limits.d too :
I don’t know what put it there. Something I installed recently was VCV Rack. This file doesn’t affect the maximum amount of memory my user can lock. I did want to figure out what had put it there.
Yes. That is the file I was talking about. I commented out the line @users - memlock 1024 and the error went away.
I made a mistake. The file is actually called
gcr is a cryptographic package. ‘users’ is an obscure group that my user is not in, so it doesn’t affect my
ulimit. ‘users’ seems to be a non-group – no-one should really be in it. It seems like a security thing, so I’m going to leave it.
the “users” group is no longer used in arch,
For some reason I must have been in the users group. When I commented out that line the error went away. I see that the better option would be to remove myself from users. In the Arch post about it, it says that those groups are no longer used but I am assuming that they still exist.
yes i installed this package too realtime-privilages. maybe this fixed my problem…
If you install
realtime-privileges you don’t need to edit
realtime-privileges takes care of all that. I don’t think the changes you made will do any harm though.
@CraigPid Yes, ‘users’ still exists. You can see a list of all groups with
cat /etc/group | sort
Most of them are for the system.
I installed realtime-privileges and added myself to the realtime group and uncommented the line in 10-gcr.conf and all is well. Thank you.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.