[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. [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 [rocketmouse@archlinux ~]$ pacman -Qi gcr Name : gcr Version : 3.28.0-4 Description : A library for bits of crypto UI and parsing Architecture : x86_64 URL : https://gitlab.gnome.org/GNOME/gcr Licenses : GPL2 Groups : None Provides : None Depends On : dconf gtk3 libgcrypt p11-kit Optional Deps : None Required By : gnome-keyring gnome-online-accounts libcryptui libgdata nm-connection-editor seahorse Optional For : pinentry Conflicts With : None Replaces : None Installed Size : 5.47 MiB Packager : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Build Date : Tue 21 Aug 2018 03:18:25 PM CEST Install Date : Tue 21 Aug 2018 09:26:46 PM CEST Install Reason : Installed as a dependency for another package Install Script : No Validated By : Signature
From: "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> To: "arch-proaudio" <arch-proaudio@lists.archlinux.org> 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.
FWIW, this doesn't happen on my system.
From: "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> To: "arch-proaudio" <arch-proaudio@lists.archlinux.org> 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.
Which are your user's groups?
$ groups wheel games video audio optical storage power users vboxusers wireshark rocketmouse vmanusers
Which is your user's default group?
$ id -g 1000 $ id -gn rocketmouse
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 $ ls -l /etc/security/ total 40 -rw-r--r-- 1 root root 4564 Jun 22 10:21 access.conf -rw-r--r-- 1 root root 3635 Jun 22 10:21 group.conf -rw-r--r-- 1 root root 2081 Apr 12 2013 limits.conf -rw-r--r-- 1 root root 1835 Jun 22 10:21 limits.conf.pacnew drwxr-xr-x 2 root root 4096 Sep 2 11:47 limits.d -rw-r--r-- 1 root root 1440 Jun 22 10:21 namespace.conf -rwxr-xr-x 1 root root 1016 Jun 22 10:21 namespace.init -rw-r--r-- 1 root root 2972 Jun 22 10:21 pam_env.conf -rw-r--r-- 1 root root 2179 Jun 22 10:21 time.conf
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 @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. ^^^^^^^^^^^ My bad. Regards, Ralf
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, 2018-09-02 at 13:59 +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!
Yes, I'll do this soon, I just dislike to change audio production related settings or to upgrade audio related software while working on a project. This is the first time that this partial maintenance does cause an issue. I would expect possible soname issues when updating all software, excepted of audio software, but I was surprised by this settings issue :D.
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 2018-09-02 16:55:49 (+0200), Fons Adriaensen wrote:
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. Well, I guess you should've started complaining about that many years ago then ;-) That change/ addition has been around for a long time! Dropin files are not only convenient for vendors, but for distributions and their packagers alike.
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. I see no problem in them. If you don't like them, you can start rolling your own distro without them ;-) 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.
Re. this 'realtime' group: I don't like that either. Groups define Well, you're not here to like everything. I also don't like a few
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. Members of other groups don't. Members of the audio group have access to certain devices (users not in
Besides: A setup like that gives the maximum amount of flexibility, which is what Linux is all about. As Arch is not Ubuntu, there's usually also no crazy amount of meta-layer configuration involved. packages I work on. I deal with them nonetheless ;-) that group don't). So, I'm unsure, what you're actually complaining about here. Should this be set for every user separately (you're completely free to do so)? The realtime group is merely a convenience layer to have a shared group, that these settings are bound to. You're entirely free to do whatever you want with pam limits. 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.
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. Best, David -- https://sleepmap.de
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 2018-09-02 17:54:36 (+0200), Ralf Mardorf wrote:
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. That's why you have to take care of what you install and when you update. /etc/security/limits.d/* has been around for many many years, so that's totally up to you to deal with that change (or not).
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. 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...
If you dislike that, or think it is utterly wrong, file a bug report against that package. -- https://sleepmap.de
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 2018-09-02 18:21:22 (+0200), Ralf Mardorf wrote:
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. That might be. Your system is super outdated. 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.
[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 This has been in that package for about 6 years. https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gcr&id=7ad066a8ca15b2556c8241b56c71b7e87385ceec
Please stop. -- https://sleepmap.de
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.
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 ;)
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 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! 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. Nitpicking regarding the "Arch approach" gains nothing. Consider to stop to sit "auf dem hohen Roß" and care about user reports.
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 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.
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.
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).
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. 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 Greetings from sunny Crete, -- FA
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
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. Begin forwarded message: Date: Sun, 2 Sep 2018 17:36:29 +0200 From: Ralf Mardorf <silver.bullet@zoho.com> 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. -- 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
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 <silver.bullet@zoho.com> 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
On Sun, 2 Sep 2018 18:21:14 +0200, David Runge wrote:
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
We were talking about users who prefer limits.conf over limits.d/* and the issue is caused by a file installed by the package gcr from the extra repository. Perhaps we should focus on Fons' observation. On Sun, 2 Sep 2018 16:55:49 +0200, Fons Adriaensen wrote:
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.
[rocketmouse@archlinux ~]$ uname -a Linux archlinux 4.18.0-rc8-rt1-1-rt-pussytoes #1 SMP PREEMPT RT Thu Aug 16 13:36:51 CEST 2018 x86_64 GNU/Linux Regards, Ralf PS: Do you really want to discuss my mistake and the behaviour of a TU named Eli Schwartz? He didn't hurt me, but he constantly hurts a lot of Arch Linux users. Not only people with missing skills, but also users who contribute a lot.
participants (4)
-
David Runge
-
Fons Adriaensen
-
Joakim Hernberg
-
Ralf Mardorf