...

From: "Ralf Mardorf" To: "arch-proaudio" Sent: Sunday, September 2, 2018 12:04:03 PM Subject: [arch-proaudio] package gcr breaks real-time settings

...

When I started Ardour yesterday, it was complaining about a memlock issue. I fixed it for my install, I only want to inform about this issue. '@users - memlock 1024' overrides 'memlock unlimited' of the audio or realtime group. What makes you think that the former actually overrides the latter? I also have gcr installed (with that limits.conf) and don't see a

On 2018-09-02 12:52:31 (+0200), Joakim Hernberg wrote: problem with Ardour (at least not in its logs). Where exactly is that problem reported? Which are your user's groups? Which is your user's default group? Do you have any other files in /etc/security/limits.d? What was your claimed fix? Questions left unanswered ;-) While all files below /etc/security/limits.d are read in C locale ordering, this would mean, that 10-gcr.conf is read first and 99-realtime-privileges.conf pretty much last. However, neither `man 5 limits.conf` nor `man 8 pam_limits` states the behavior of a user being in two different groups with diverging settings. I hope that's not undefined... ;-) -- https://sleepmap.de

On Sun, 2018-09-02 at 13:15 +0200, David Runge wrote:

...

Where exactly is that problem reported? An Ardour 5.8.0 window informs about the issue, when starting ardour. I'm not using Ardour from the repository, since I not always upgrade audio software during an audio production. That means, the reporting could be faulty. 5.12 does not report that issue. Please refer to upstream as to how stuff is reported, if this

On 2018-09-02 13:41:07 (+0200), Ralf Mardorf wrote: problem persists (which I don't think it will, as it's hidden in your setup).

...

Which are your user's groups?

$ groups wheel games video audio optical storage power users vboxusers wireshark rocketmouse vmanusers Your user is not even in the realtime group!

...

Which is your user's default group?

$ id -g 1000 $ id -gn rocketmouse Seems to be unrelated then.

...

Do you have any other files in /etc/security/limits.d?

$ ls -l /etc/security/limits.d/ total 4 -rw-r--r-- 1 root root 45 Sep 2 11:47 10-gcr.conf Aha! You don't have the realtime-privileges installed to begin with.

...

What was your claimed fix?

Commenting out '@users - memlock 1024'.

$ cat /etc/security/limits.d/10-gcr.conf #@users - memlock 1024

# vim:set ft=limits: $ tail -2 /etc/security/limits.conf @audio - rtprio 99 I would advice against rtprio 99

@audio - memlock unlimited

...

While all files below /etc/security/limits.d are read in C locale ordering, this would mean, that 10-gcr.conf is read first and 99-realtime-privileges.conf pretty much last. However, neither `man 5 limits.conf` nor `man 8 pam_limits` states the behavior of a user being in two different groups with diverging settings. I hope that's not undefined... ;-)

So the issue seemingly is, that I use /etc/security/limits.conf and not /etc/security/limits.d/99-foo.conf. ^^^^^^^^^^^ Yes, and your user is not in the realtime group.

10-gcr.conf is read *after* /etc/security/limits.conf, which explains your observed behavior. The use of the plain /etc/security/limits.conf is discouraged over the use of drop-in files in /etc/security/limits.d anyways! Please use those! Best, David -- https://sleepmap.de

On Sun, Sep 02, 2018 at 01:59:46PM +0200, David Runge wrote:

.... The use of the plain /etc/security/limits.conf is discouraged over the use of drop-in files in /etc/security/limits.d anyways! Please use those!

Well, I have mixed feelings about these 'drop-in' directories which seem to pop up everywhere. They may be very convenient for 'vendors' (the one who introduced that concept to Linux should be shot) but they are are a security nightmare for the local admin. Instead of having to check one file which defines some policy, you now have to check a whole collection every time some 'vendor' could have 'dropped' something. Somehow this reminds me of dogs. Take systemd's logind. You have to verify a config file and *three* directories in order to have any idea of how things are configured in the end. And oh, yes, you can override everything in /etc. But that effectively means you need to opt out of whatever some 'vendor' pushes down your throat. Not once, but everytime you update. Re. this 'realtime' group: I don't like that either. Groups define a set of users with common needs. So *all* features or permissions that members of a group need should be made dependent on being a member of that group and nothing else. This is entirely the opposite of defining groups for one particular feature such as real time and then requiring users to be a member of all of them. For what it's worth, I noticed that after upgrading to kernel 4.18 I had to increase the memlock limit to avoid error messages almost all audio applications. Ciao, -- FA

On Sun, 2 Sep 2018 17:35:17 +0200, David Runge wrote:

Given the fact, that (at least with logind directly) on Arch there are absolutely no dropin files included, this is somewhat of a moot point you're bringing up btw.

Actually an upgrade (extra/gcr) installed /etc/security/limits.d/10-gcr.conf on my Arch Linux install.

In fact, if you dislike the realtime group so much, you don't even have to install the realtime-privileges package! You can just set this up in /etc/security/limits.conf all by yourself. Noone stops you from doing that.

That is what I'm doing and I was surprised that a package installed /etc/security/limits.d/10-gcr.conf.

On Sun, 2 Sep 2018 18:00:54 +0200, David Runge wrote:

AFAICS that has been in gcr for a very long time, too: https://git.archlinux.org/svntogit/packages.git/log/trunk/10-gcr.conf?h=pack...

The first time I noticed this issue was yesterday. I don't remember when I run Ardour the last time, but it was within the end of last year or much more likely even within this year, at worst it was 02 Mar 2017. [rocketmouse@archlinux ~]$ pacman -Qi ardour5 | grep Install\ Date Install Date : Thu 02 Mar 2017 07:27:36 PM CET To me the issue is brand-new. [rocketmouse@archlinux ~]$ grep gcr\ /var/log/pacman.log | tail -9 [2016-04-10 19:58] [ALPM] upgraded gcr (3.18.0-1 -> 3.20.0-1) [2016-07-30 11:50] [ALPM] upgraded gcr (3.20.0-1 -> 3.20.0-2) [2016-10-23 19:56] [ALPM] upgraded gcr (3.20.0-2 -> 3.20.0+11+g8322f27-1) [2017-04-25 02:09] [ALPM] upgraded gcr (3.20.0+11+g8322f27-1 -> 3.20.0+45+g4708f35-1) [2017-10-19 07:51] [ALPM] upgraded gcr (3.20.0+45+g4708f35-1 -> 3.20.0+55+g470bf4c-1) [2018-03-26 22:52] [ALPM] upgraded gcr (3.20.0+55+g470bf4c-1 -> 3.28.0-1) [2018-04-29 07:29] [ALPM] upgraded gcr (3.28.0-1 -> 3.28.0-2) [2018-05-03 05:20] [ALPM] upgraded gcr (3.28.0-2 -> 3.28.0-3) [2018-08-21 21:26] [ALPM] upgraded gcr (3.28.0-3 -> 3.28.0-4) [rocketmouse@archlinux ~]$ ls -hAl /etc/security/limits.d/ total 4.0K -rw-r--r-- 1 root root 45 Sep 2 11:47 10-gcr.conf [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 There was no such issue within the last years. Since Fons mentioned the kernel version: [rocketmouse@archlinux ~]$ uname -rm 4.18.0-rc8-rt1-1-rt-pussytoes x86_64 Regards, Ralf

On Sun, 2018-09-02 at 18:32 +0200, David Runge wrote:

That might be. Your system is super outdated.

No, it isn't. Consider to read my emails more carefully. A few apps are not up to date for good reasons, but those apps aren't the cause for the issue.

On Sun, 2018-09-02 at 19:05 +0200, Joakim Hernberg wrote:

Ralf, do you honestly not think you are making a mountain out of a molehill?

Just install the realtime-privileges package, remove yourself from the audio group and add yourself to the realtime group, and then go record some music...

P.S. Take care of your .pacnew files too ;)

The issue on my install already was solved before I send my email, that's not the point.

On 2018-09-02 19:08:11 (+0200), Ralf Mardorf wrote:

On Sun, 2 Sep 2018 18:32:42 +0200, David Runge wrote:

...

We are not Debian. Arch is rolling release. We don't support partial upgrades and we also don't support versions of whatever from last year.

Please stop posting the same information over and over again. This is getting really annoying.

Stop to behave in an insane way as Eli Schwartz does! Read the information more carefully instead of ignoring it and just mention the "Arch approach" to cover your ignorance! Given the fact that you've now chosen the path of making personal attacks (again), I have put you on moderation. The only one who is being ignorant here, is you. I have suggested to you what your problem with your configuration is. I even gave you and also Fons possible ways of configuring your system in such a way, that you don't have to use dropin files (which have been around for along time, but that's another story).

We are all Arch users with different skills, but note, you are in contact with several professional (current and former) audio engineers using Linux for more than a decade. At least two of them have an objection that isn't conformable for your point of view. IIRC the "Arch approach" covers the KISS principle as well as user's customization. Stop using the Arch lists for accusations of this kind. I'm perfectly aware of other people's skill sets and preferences, which is why I gave a suggestion on how you can use your setup without the realtime-privileges package. I spend a considerable amount of my free time actually trying to improve

I'm tired of reading your insults and repetitive information, about a problem that you have because of a partial upgrade (which we don't support - period). This has nothing to do with your ability to maneuvre a Linux system. This has something to do with you ignoring what people answer and suggest and spamming every Arch list with arbitrary information (even after you problem is solved) and wasting all of our time (and then turning to personal attacks). the infrastructure and (pro-audio) packaging in Arch. What you do here is toxic and condescending and sucks out all the fun out of doing that.

Nitpicking regarding the "Arch approach" gains nothing. Consider to stop to sit "auf dem hohen Roß" and care about user reports. I'm not sitting "on the high horse" here. I've offered my help. And you rant.

Btw: Fons didn't give very detailed information on what actually his problems are yet (besides a lot of emotional context about dropin configuration files and group usage). He's entitled to have that. I'm entitled to ask for further information regarding his reported problems. There's nothing more to that. Best, David -- https://sleepmap.de

On 2018-09-02 21:52:33 (+0200), Fons Adriaensen wrote:

On Sun, Sep 02, 2018 at 05:35:17PM +0200, David Runge wrote:

...

Well, I guess you should've started complaining about that many years ago then ;-)

Maybe I should have... But if the standard answer is 'you can always roll you own', then expressing any opinion or preference becomes sort of pointless. I'm not sure that would be the standard answer. However, with free software you at least have that possibility!

...

...

a set of users with common needs. So *all* features or permissions that members of a group need should be made dependent on being a member of that group and nothing else. This is entirely the opposite of defining groups for one particular feature such as real time and then requiring users to be a member of all of them. I don't exactly understand your logic here: Members of the realtime group *share* the same common needs. They ought to be able to acquire realtime scheduling for their processes.

The logic is: for audio you need access to audio devices, be able to run real-time processes, and be able to lock memory. So create a group that has all these privileges. For any other type of activities do the same.

It's just a different way of organising groups. Instead of having groups for each single particular privilege, and require users to be a member of a mix of them, define a single group which combines whatever is required for some type of activity.

BTW, following what I assume is your logic, the 'realtime' group should be split in two, one for real time and one for memory locking. That's a valid point and could potentially be done in the future. The idea behind the realtime-privileges package is, that it can be reused (depended upon by other packages) or just used for non-single purposes (apart from audio). Additionally a decoupling from the audio group was sought after, because otherwise one instantly has a larger group of users with access to those permissions, only because they are in the audio group. Indeed a more granular approach to grouping!

Thanks for explaining your reasoning. I now get what you meant! However, from a packaging standpoint, it makes more sense to have one package that offers functionality, than to redundantly package the same files in many packages (also makes it much faster to adapt them!).

...

So, I'm unsure, what you're actually complaining about here.

I'm not complaining. Just preferred the way it was done before (give the audio group whatever is needed for audio). I see. Sorry, if I misinterpreted that then.

...

...

For what it's worth, I noticed that after upgrading to kernel 4.18 I had to increase the memlock limit to avoid error messages almost all audio applications. With what exact setup is that? Which components are involved? How do you configure your users and limits? Are you using the realtime-privileges group? Is your user in the realtime group?

...

Ask a specific question and we'll try to give a specific answer.

I didn't ask any questions, only reported that I noticed something related to memory locking had changed. Which seemed to be on-topic. I see. The kernel 4.18 most likely doesn't have much to do with it though, but changes to the (now) gcr dependants [1], that you had installed before. As gcr is required by many packages it is entirely possible, that the limits file in question got installed when updating something, that now requires gcr.

But to answer your questions:

* Archliux updated last two days ago. * Jack, all audio apps using Jack (most of them my own). * Using the 'audio' group, which has realtime and memlock entries in limits.conf. * No * No Hm, in this case you can only remove whatever requires gcr and gcr or edit its limits configuration (to keep using /etc/security/limits.conf directly) or start using dropin files below /etc/security/limits.d (which is recommended).

Best, David [1] https://www.archlinux.org/packages/extra/x86_64/gcr/ -- https://sleepmap.de

On 2018-09-02 17:44:16 (+0200), Ralf Mardorf wrote:

Since arch general is under moderation, I forward a mail to this list. Instead of shooting the developer/s who introduced the concept of drop-in directories IMO an announcement would be appropriate. I wonder why that is ;-)

Date: Sun, 2 Sep 2018 17:36:29 +0200 From: Ralf Mardorf To: arch-general@archlinux.org Subject: Re: [arch-general] users memlock value

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. I'm unsure I understand what you're writing about here. We all have been using dropin files with the jack/jack2 package for many years (where one had to add their users to the audio group, too, to access hardware - and ugly enough realtime in the same vein).

The realtime-privileges package is a new optional dependency (and is flagged as such during upgrade of jack/jack2). Users and admins are supposed to read what happens during system upgrade. I can't help people reading! Therefore, there is no need for any announcement here, as this is all completely non-mandatory (optional dependency), too! What makes you think anyone would read an announcement, if that person doesn't read an upgrade message? If this [1] is not enough, I don't know what is. [1] https://lists.archlinux.org/pipermail/arch-proaudio/2018-August/000191.html -- https://sleepmap.de