users memlock value

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

users memlock value

Ralf Mardorf-4
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
Reply | Threaded
Open this post in threaded view
|

Re: users memlock value

Ralf Mardorf-4
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.
Reply | Threaded
Open this post in threaded view
|

Re: users memlock value

David Runge
In reply to this post by Ralf Mardorf-4
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.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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: users memlock value

Ralf Mardorf-4
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.html

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

Regards,
Ralf
Reply | Threaded
Open this post in threaded view
|

Re: users memlock value

Ralf Mardorf-4
In reply to this post by David Runge
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.
Reply | Threaded
Open this post in threaded view
|

Re: users memlock value

Ralf Mardorf-4
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.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