[arch-general] users memlock value
Hi, I wonder if it's reasonable, that a package sets an '@users - memlock' value, since it overrides needed memlock values of other groups. [rocketmouse@archlinux ~]$ cat /etc/security/limits.d/10-gcr.conf @users - memlock 1024 # vim:set ft=limits: [rocketmouse@archlinux ~]$ pacman -Qo /etc/security/limits.d/10-gcr.conf /etc/security/limits.d/10-gcr.conf is owned by gcr 3.28.0-4 Regards, Ralf
On Sun, 2 Sep 2018 12:14:51 +0200, Ralf Mardorf wrote:
I wonder if it's reasonable, that a package sets an '@users - memlock' value, since it overrides needed memlock values of other groups.
[rocketmouse@archlinux ~]$ cat /etc/security/limits.d/10-gcr.conf @users - memlock 1024
# vim:set ft=limits: [rocketmouse@archlinux ~]$ pacman -Qo /etc/security/limits.d/10-gcr.conf /etc/security/limits.d/10-gcr.conf is owned by gcr 3.28.0-4
My bad. I'm using /etc/security/limits.conf instead of /etc/security/limits.d/SOME_HIGH_NUMBER-foo.conf to set another value for memlock.
On 2018-09-02 12:14:51 (+0200), Ralf Mardorf wrote:
I wonder if it's reasonable, that a package sets an '@users - memlock' value, since it overrides needed memlock values of other groups. Guess we can safely file this under "misconfiguration"? https://lists.archlinux.org/pipermail/arch-proaudio/2018-September/000199.ht...
Also, please don't double post your issues. Give people time to actually respond. No need to post to arch-general, if you brought this up before. This is not an instant messenger service. Best, David -- https://sleepmap.de
On Sun, 2 Sep 2018 14:02:42 +0200, David Runge wrote:
Guess we can safely file this under "misconfiguration"?
Yes! Ass already pointed out by https://lists.archlinux.org/pipermail/arch-general/2018-September/045550.htm... (and for detailed explanation why this happened https://lists.archlinux.org/pipermail/arch-proaudio/2018-September/000200.ht... ). Regards, Ralf
On Sun, 2 Sep 2018 14:02:42 +0200, David Runge wrote:
Also, please don't double post your issues. Give people time to actually respond. No need to post to arch-general, if you brought this up before. This is not an instant messenger service.
PS: Independent of what is required for a realtime (or the old audio) group and that there is no issue when using limits.d/file_with_a_higher_number.conf , I still question that '@users - memlock 1024' should be set by package. I doubt that a default 'memlock 1024' for the 'users' group is a good choice at all.
On Sun, 2 Sep 2018 16:02:37 +0200, Ralf Mardorf wrote:
On Sun, 2 Sep 2018 14:02:42 +0200, David Runge wrote:
Also, please don't double post your issues. Give people time to actually respond. No need to post to arch-general, if you brought this up before. This is not an instant messenger service.
PS: Independent of what is required for a realtime (or the old audio) group and that there is no issue when using limits.d/file_with_a_higher_number.conf , I still question that '@users - memlock 1024' should be set by package. I doubt that a default 'memlock 1024' for the 'users' group is a good choice at all.
PPS: And I forgot to mention, what Fons' pointed out and actually was the issue that I experienced: On Sun, 2 Sep 2018 16:55:49 +0200, Fons Adriaensen wrote:
But that effectively means you need to opt out of whatever some 'vendor' pushes down your throat. Not once, but everytime you update.
The link to the complete message: https://lists.archlinux.org/pipermail/arch-proaudio/2018-September/000201.ht... So at least an announcement via https://lists.archlinux.org/listinfo/arch-announce should be considered. -- pacman -Q linux{,-rt{-pussytoes,-cornflower,,-securityink}}|cut -d\ -f2 4.18.5.arch1-1 4.18_rc8_rt1-1 4.16.18_rt12-1 4.16.18_rt11-1 4.16.18_rt10-1
participants (2)
-
David Runge
-
Ralf Mardorf