I have several Linux machines, all of them running the same kernel (Ubuntu 12.04, 3.5.0-45-generic). On one of them, I am unable to use chrt at all. If I attempt to use it on a new process, I get the following error:

$ sudo chrt -f 1 ls
chrt: failed to set pid 0's policy: Operation not permitted

If I attempt to use it on an existing process, I get a similar error:

$ stress -c 1 &
[1] 3929
$ sudo chrt -f -p 1 3929
chrt: failed to set pid 3929's policy: Operation not permitted

I'm operating as super-user so I should have CAP_SYS_NICE, and I am indeed able to nice or renice a process; I just can't adjust its real-time properties.

This behavior is unique to this one machine; the behavior persists through reboot and launching a new shell in a stripped environment (env -i bash --noprofile --norc).

If I attempt to run this command on any of the other machines (all the same distribution, but some with different hardware) it succeeds as expected.

The closest to an explanation I found was this Google groups posting in which someone asserted that the same problem was because of the use of cpuset. I was unable to find any elaboration. I have previously done some work on this machine with thread affinities (pthread_setaffinity_np()), taskset, cpusets, isolcpus, etc. However, I don't know how any of those could still be causing this behavior, since I'm not explicitly setting any priorities, and e.g. taskset -p $$ shows the full set of CPUs (as expected). Also, I've double-checked that I'm not still running with any CPUs isolated (cat /proc/cmdline).

Is there any configuration I'm overlooking? Any suggestions would be greatly appreciated

EDIT As per @bersch's suggestion, I'm including excerpts from running strace. On a working machine setting to priority 13:

sched_setscheduler(2475, SCHED_FIFO, { 13 }) = 0 # PID 2475
sched_setscheduler(0, SCHED_FIFO, { 13 }) = 0 # ls 

The same on the broken machine:

sched_setscheduler(6248, SCHED_FIFO, { 13 }) = -1 EPERM (Operation not permitted) # PID 6248
sched_setscheduler(0, SCHED_FIFO, { 13 }) = -1 EPERM (Operation not permitted) # ls

This is exactly what I would expect from the error messages.

  • you could compare /boot/config-* settings if you really run the same kernel and for example check for sched_setscheduler with strace -f chrt -f 1 ls – user55518 Feb 10 '14 at 23:50
  • Thanks for the suggestions! The contents are indeed identical. I updated the original post with the strace. – Tom Feb 11 '14 at 2:18

I had the same problem. The following command fixed it:

sysctl -w kernel.sched_rt_runtime_us=-1

Source: https://lists.opensuse.org/opensuse-security/2011-04/msg00015.html

| improve this answer | |

The Google Groups post and @bersch's suggestion to look for the sched_setscheduler call directly (instead of the chrt command-line wrapper) got me to an answer: it was indeed because of my use of cpuset. I had forgotten that cgroups is used to support cpusets.

A search for sched_getscheduler and cgroup turned up a ton of hits, including


At any rate, I currently have no need for cgroups at all, so I just disabled it:

sudo service cgconfig stop

Now everything works as expected.

Edit To get the change to persist after reboot, I had to comment out the contents of /etc/cgconfig.conf as well.

| improve this answer | |
  • what's the name of the package in Ubuntu that uses cgconfig? – user55518 Feb 11 '14 at 16:12
  • @bersch: According to dpkg, it was libcgroup1, though I think I installed that as a dependency of something higher level, e.g. cpuset. – Tom Feb 11 '14 at 19:29
  • you get the info with dpkg -S /etc/cgconfig.conf – user55518 Feb 11 '14 at 19:31
  • ... that was what I meant by "According to dpkg" – Tom Feb 13 '14 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.