Discussion:
users memlock value
Add Reply
Ralf Mardorf
2018-09-02 10:14:51 UTC
Reply
Permalink
Raw Message
Hi,

I wonder if it's reasonable, that a package sets an
'@users - memlock' value, since it overrides needed memlock values of
other groups.

[***@archlinux ~]$ cat /etc/security/limits.d/10-gcr.conf
@users - memlock 1024

# vim:set ft=limits:
[***@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
Ralf Mardorf
2018-09-02 11:41:10 UTC
Reply
Permalink
Raw Message
Post by Ralf Mardorf
I wonder if it's reasonable, that a package sets an
other groups.
@users - memlock 1024
-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.
David Runge
2018-09-02 12:02:42 UTC
Reply
Permalink
Raw Message
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.html

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
Ralf Mardorf
2018-09-02 13:40:14 UTC
Reply
Permalink
Raw Message
Post by David Runge
Guess we can safely file this under "misconfiguration"?
Yes!

Ass already pointed out by

https://lists.archlinux.org/pipermail/arch-general/2018-September/045550.html

(and for detailed explanation why this happened
https://lists.archlinux.org/pipermail/arch-proaudio/2018-September/000200.html ).

Regards,
Ralf
Ralf Mardorf
2018-09-02 14:02:37 UTC
Reply
Permalink
Raw Message
Post by David Runge
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.
Ralf Mardorf
2018-09-02 15:36:29 UTC
Reply
Permalink
Raw Message
Post by Ralf Mardorf
Post by David Runge
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
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
Post by Ralf Mardorf
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.html

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
Loading...