Bug 785778

Summary:	media-video/pipewire-0.3.* installs 40-pipewire.conf with memlock limit 256K
Product:	Gentoo Linux	Reporter:	Anton Gubarkov <anton.gubarkov>
Component:	Current packages	Assignee:	Gentoo Linux Gnome Desktop Team <gnome>
Status:	RESOLVED FIXED
Severity:	normal	CC:	asturm, ionen, sam, whissi
Priority:	Normal	Keywords:	PullRequest
Version:	unspecified
Hardware:	All
OS:	Linux
See Also:	https://github.com/gentoo/gentoo/pull/20454 https://github.com/gentoo/gentoo/pull/20707
Whiteboard:
Package list:		Runtime testing required:	---

Description Anton Gubarkov 2021-04-26 06:10:47 UTC

I'm running my Gentoo as  a DAW (on jack). My memlock limits are set quite high due to the requirements of jack and ardour6.

the pipewire was silently introduced into my system as a gnome-shell dependency.
It installs a file into the /etc/security/limits.d that clamps memlock at 256K - far too low for my DAW.

I spend a couple of days searching why I'm memlock limited all of a sudden. 

I think the file should have this line commented:
1000:60000     -       memlock 256
It is based on userids and overrides the traditional approach to have the member of @audio or @realtime memlock unlimited.
i don't run pipewire as a pulseaudio/jack replacement. It was just pulled in as the dependency.

The warning in the ebuild should alert users to enable it if needs to, from my PoV

Comment 1 Niklāvs Koļesņikovs 2021-04-26 09:08:35 UTC

I'm sorry to hear about that. In my testing the sys-auth/realtime-base seemed to take precedence, so I assumed it will be okay. I will be retesting this once more but in the meantime you can either set INSTALL_MASK="/etc/security/limits.d/40-pipewire.conf" in make.conf or use package.env to set INSTALL_MASK="/etc/security/limits.d" on specifically media-video/pipewire.

Comment 2 Niklāvs Koļesņikovs 2021-04-26 11:28:04 UTC

Turns out I was probably using the realtime early on, and by the time the limits.d/ file was made things were pretty hectic, so it might have slipped my mind to double check if @realtime can still override it. Turns out - UID range is probably stronger match than any @<group> and will take precedence disregarding the lexicographical order of limits.d/ files.

As such this is the best solution, I could come up with (i.e. replace 1000:6000 UID range with * for default marker, which can be overridden by @realtime):
*       -       memlock 256

If no one voices any objections in this bug, I'll try to get that included in one of the future ebuilds.

Comment 3 Anton Gubarkov 2021-04-26 11:43:22 UTC

Seems to work fine for me

Comment 4 Larry the Git Cow gentoo-dev

2021-05-08 18:27:52 UTC

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=274f08964197fac2907863311e36c0afbb58d381

commit 274f08964197fac2907863311e36c0afbb58d381
Author:     Thomas Deutschmann <whissi@gentoo.org>
AuthorDate: 2021-05-08 14:07:53 +0000
Commit:     Thomas Deutschmann <whissi@gentoo.org>
CommitDate: 2021-05-08 18:27:45 +0000

    media-video/pipewire: raise RLIMIT_MEMLOCK to 256 by default for audio group
    
    Closes: https://bugs.gentoo.org/785778
    Package-Manager: Portage-3.0.18, Repoman-3.0.3
    Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>

 media-video/pipewire/pipewire-9999.ebuild | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)