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
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.
arch-general@lists.archlinux.org