On Thu, 28 Feb 2013 17:07:06 +0200
Hartmut Behrens <hartmut.behrens@xxxxxxxxx> wrote:
> On Wed, Feb 27, 2013 at 10:00 PM, Clark Williams <williams@xxxxxxxxxx> wrote:
> > Well this is a new one on me. Some questions:
> >
> > Do you have SELinux running?
>
> No SELinux is disabled
>
> >
> > Are there any files in /etc/security/limits.d other than the one you put
> > there?
> >
> Yes there are:
>
> root@overo:/etc/security# ls -l
> total 40
> -rw-r--r-- 1 root root 4620 Feb 26 2013 access.conf
> -rw-r--r-- 1 root root 3635 Feb 26 2013 group.conf
> -rw-r--r-- 1 root root 1825 Feb 26 2013 limits.conf
> drwxr-xr-x 2 root root 4096 Feb 26 2013 limits.d
> -rw-r--r-- 1 root root 1442 Feb 26 2013 namespace.conf
> drwxr-xr-x 2 root root 4096 Feb 26 2013 namespace.d
> -rwxr-xr-x 1 root root 1020 Feb 26 2013 namespace.init
> -rw-r--r-- 1 root root 2980 Feb 26 2013 pam_env.conf
> -rw-r--r-- 1 root root 2180 Feb 26 2013 time.conf
>
>
> > Other than that I can't think of a reason why sched_setscheduler()
> > would fail as root.
That's /etc/security, I was asking for /etc/security/limits.d.
Since you said that disabling RT_GROUP_SCHED fixed it, I looked at
kernel/sched/core.c and found this block of code in
__sched_setscheduler():
#ifdef CONFIG_RT_GROUP_SCHED
if (user) {
/*
* Do not allow realtime tasks into groups that have no runtime
* assigned.
*/
if (rt_bandwidth_enabled() && rt_policy(policy) &&
task_group(p)->rt_bandwidth.rt_runtime == 0 &&
!task_group_is_autogroup(task_group(p))) {
task_rq_unlock(rq, p, &flags);
return -EPERM;
}
}
#endif
There are plenty of places in __sched_setscheduler() to get punted out
with -EPERM, but this looks likely. My guess is that you have something
going on (or not going on) wrt cgroups and you got kicked out by one of
the above tests.
I think if you look at the RT wiki, it recommends not turning on
RT_GROUP_SCHED for PREEMPT_RT systems (if it doesn't, it *should*).
Clark
Attachment:
signature.asc
Description: PGP signature
