Re: [systemd-devel] Real-time permission affected by root login on other tty
On Sun, Mar 8, 2015 at 11:27 PM, Lennart Poettering lenn...@poettering.net wrote: Most likely you have RT cgroup scheduling enabled in the kernel, and some unit uses CPUShares=, CPUAccounting=, CPUQuota*= in the unit file. If a unit does that this will move the unit's cgroup into the cpu cgroup controller, as well as all its parent and sibling cgroups (and thus units). I can only find a commented out CPUAccounting= in /etc/systemd/system.conf. No other configuration file mention the above parameters. I'm on a fresh install of Arch. When a process is in a cgroup in the cpu controller, and no RT budget is set for that cgroup, then RT is not available to it. This is very unfortunate. I'd love to assign an RT budget by default from systmed, but this isn't really doable, since there's no sane RT budget one could assign a cgroup given the current semantics of it (which require that all RT budgets of cgroups within another cgroup must sum up to less than 1/1...). Here's the output of /proc/self/cgroup when logging in as non-root user while root is logged in other vconsole or via ssh: 8:memory:/user.slice/user-1000.slice 7:blkio:/user.slice/user-1000.slice 6:cpuset:/ 5:cpu,cpuacct:/user.slice/user-1000.slice 4:devices:/user.slice/user-1000.slice 3:net_cls:/ 2:freezer:/ 1:name=systemd:/user.slice/user-1000.slice/session-c3.scope When logging in as non-root alone, or when downgrading to systemd-216: 8:memory:/ 7:blkio:/ 6:cpuset:/ 5:cpu,cpuacct:/ 4:devices:/ 3:net_cls:/ 2:freezer:/ 1:name=systemd:/user.slice/user-1000.slice/session-c1.scope -- Lars ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Real-time permission affected by root login on other tty
On Sat, 07.03.15 20:04, Lars Christensen (lar...@belunktum.dk) wrote: With systemd 218 and 219, I have a strange issue that processes running as root cannot acquire realtime priority (SCHED_RR, priority 22). Further, if (and only if) root is logged in (via tty or ssh), users processes can also not acquire realtime priority. If root is NOT logged in, user processes CAN acquire real time priority(!). Most likely you have RT cgroup scheduling enabled in the kernel, and some unit uses CPUShares=, CPUAccounting=, CPUQuota*= in the unit file. If a unit does that this will move the unit's cgroup into the cpu cgroup controller, as well as all its parent and sibling cgroups (and thus units). When a process is in a cgroup in the cpu controller, and no RT budget is set for that cgroup, then RT is not available to it. This is very unfortunate. I'd love to assign an RT budget by default from systmed, but this isn't really doable, since there's no sane RT budget one could assign a cgroup given the current semantics of it (which require that all RT budgets of cgroups within another cgroup must sum up to less than 1/1...). THis is something that needs to be cleaned up in the kernel, and then we can expose this nicer in systemd. For now, my recommendation would be to disable the RT cgroup stuff in the kernel, and thus forego the whole problem. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Real-time permission affected by root login on other tty
With systemd 218 and 219, I have a strange issue that processes running as root cannot acquire realtime priority (SCHED_RR, priority 22). Further, if (and only if) root is logged in (via tty or ssh), users processes can also not acquire realtime priority. If root is NOT logged in, user processes CAN acquire real time priority(!). With systemd 216 there is no issue. I'm on Arch Linux. To reproduce: Method 1: 1. Login on tty1 as as root 2. Execute program that attempts to acquire realtime priority. Method 2: 1. Login on tty1 as root 2. Log in on tty2 as other user 3. Execute program that attempts to acquire realtime priority on tty2 If step 1 is skipped in method 2, or logged in before root, the program runs normally (as non-root user) (assuming appropriate rlimit via /etc/security/limits.conf). strace output: sched_setscheduler(183, SCHED_RR, { 22 }) = -1 EPERM (Operation not permitted) ulimit -r (as root): 0 (but should be able to do realtime as root anyway) ulimit -r (as user): 65 (via /etc/security/limits.conf, audio group) Downgrading only systemd, systemd-sysvcompat, libsystemd to 216 fixes the issue. With 218 and 219 I get the EPERM above. Source code for test program: https://gist.github.com/larsch/58d1be84b24c98a4493f Bug or PEBKAC? -- Lars ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel