| Summary: | realtime and memlock limits needed for jackd (jackit package) not provided to user in plasma | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | david gritter <dvdgrttr> |
| Component: | Installer | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, kde, marja11, smelror, smout.jan, sysadmin-bugs |
| Version: | 9 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA9-64-OK | ||
| Source RPM: | systemd-253.10-1.1.mga9 | CVE: | |
| Status comment: | |||
|
Description
david gritter
2023-08-29 06:03:52 CEST
Thank you for the report. Unsure where the fault lies: jackit or Plasma. Assigning globally because jackit does not have a regular maintainer. Assignee:
bugsquad =>
pkg-bugs I have exactly the same issue. I used to run Ardour with jack or alsa flawlessly on plasma in mageia 8. But now it has has become unusable in plasma due to xruns. On a VT: [jan@escher ~]$ ulimit -r 99 [jan@escher ~]$ strace -e sched_setscheduler chrt -f 80 /bin/true sched_setscheduler(0, SCHED_FIFO, [80]) = 0 +++ exited with 0 +++ In a terminal, when logged into Plasma: [jan@escher ~]$ ulimit -r 0 [jan@escher ~]$ strace -e sched_setscheduler chrt -f 80 /bin/true sched_setscheduler(0, SCHED_FIFO, [80]) = -1 EPERM (Operation not permitted) chrt: failed to set pid 0's policy: Operation not permitted +++ exited with 1 +++ Normally pam_limits takes care of /etc/security/limits... but, comparing mageia 8 and 9, I see many more systemd units popping up for plasma. So, could it be related to this ? https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#LimitCPU= At least 2 options are relevant: LimitRTPRIO=infinity LimitMEMLOCK=infinity but I'm not knowledgeable enough on systemd units to figure out which one(s) would need a patch. I tried a few of them without success so far. There is also the possibility it's a bug in systemd. Have a look at the following: https://github.com/systemd/systemd/issues/29446 Wouldn't that imply that systemd should be respecting /etc/security/limits... ? CC:
(none) =>
smout.jan Following the crumbs of my last sentence I found something here: https://github.com/systemd/systemd/pull/11448 It appears to have been addressed 5 years ago, but we need to tell systemd to use pam_limits for it to work Adding the following line to /etc/pam.d/systemd-user session required pam_limits.so and a reboot (yep, relogin blocked on sddm login... it spawned a second systemd --user session, uggh) worked for me. $ ulimit -r 99 $ grep -E locked\ memory\|realtime\ priority /proc/$(pidof systemd)/limits Max locked memory unlimited unlimited bytes Max realtime priority 99 99 ...and jack and Ardour are happy again ^_^ Changing the source rpm as /etc/pam.d/systemd-user is owned by systemd. Adding Stig-Ørjan to cc list as the latest packager to make changes to systemd. CC:
(none) =>
davidwhodgins, smelror systemd 253.12-2 built for Cauldron. Advisory ======== systemd-users was missing pam_limits.so for realtime audio for use with jackd. Adding this so that it works as expected. References ========== Files ===== Uploaded to core/updates_testing lib64udev-devel-253.10-1.2.mga9 lib64udev1-253.10-1.2.mga9 systemd-devel-253.10-1.2.mga9 systemd-homed-253.10-1.2.mga9 lib64systemd0-253.10-1.2.mga9 nss-myhostname-253.10-1.2.mga9 systemd-tests-253.10-1.2.mga9 systemd-253.10-1.2.mga9 from systemd-253.10-1.2.mga9.src.rpm Assignee:
pkg-bugs =>
qa-bugs installed and tested ok for systemd-253.10-1.2.mga9
Marja Van Waes
2024-02-14 16:14:21 CET
CC:
(none) =>
marja11 Validating Whiteboard:
(none) =>
MGA9-64-OK An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2024-0054.html Status:
NEW =>
RESOLVED |