Re: [systemd-devel] Real-time permission affected by root login on other tty

[Lars Christensen]

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

[systemd-devel] Real-time permission affected by root login on other tty

[Lars Christensen]

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