我有几台 Linux 机器，它们都运行相同的内核（Ubuntu 12.04，3.5.0-45-generic）。其中之一，我chrt根本无法使用。如果我尝试在新进程中使用它，则会收到以下错误：
$ sudo chrt -f 1 ls
chrt: failed to set pid 0's policy: Operation not permitted
如果我尝试在现有进程中使用它，我会收到类似的错误：
$ stress -c 1 &
[1] 3929
$ sudo chrt -f -p 1 3929
chrt: failed to set pid 3929's policy: Operation not permitted
我作为超级用户操作，所以我应该有CAP_SYS_NICE，而且我确实能够nice或renice一个过程；我只是无法调整其实时属性。
这种行为是这台机器独有的；通过重新启动并在剥离的环境 ( env -i bash --noprofile --norc) 中启动新 shell，该行为仍然存在。
如果我尝试在任何其他机器（所有相同的发行版，但有些具有不同的硬件）上运行此命令，它会按预期成功。
最接近我发现的解释是这个 Google 组的帖子，其中有人断言同样的问题是因为使用了 cpuset。我找不到任何详细说明。我之前在这台机器上做过一些线程亲和性 ( pthread_setaffinity_np())、taskset、cpusets、isolcpus 等工作。但是，我不知道这些中的任何一个仍然会导致这种行为，因为我没有明确设置任何优先级, 和 egtaskset -p $$显示完整的 CPU 集（如预期的那样）。此外，我已经仔细检查过，我没有仍在使用任何孤立的 CPU ( cat /proc/cmdline) 运行。
有没有我忽略的配置？任何建议将不胜感激
编辑
根据@bersch 的建议，我包括了 running 的摘录strace。在设置为优先级 13 的工作机器上：
sched_setscheduler(2475, SCHED_FIFO, { 13 }) = 0 # PID 2475
sched_setscheduler(0, SCHED_FIFO, { 13 }) = 0 # ls
在损坏的机器上也是如此：
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
这正是我对错误消息的期望。
我有同样的问题。以下命令修复了它：
sysctl -w kernel.sched_rt_runtime_us=-1
来源：https ://lists.opensuse.org/opensuse-security/2011-04/msg00015.html
Google 网上论坛的帖子和@bersch 建议直接查找调用sched_setscheduler（而不是chrt命令行包装器）让我得到了答案：这确实是因为我使用了 cpuset。我忘记了cgroups是用来支持cpusets的。
搜索sched_getscheduler并cgroup发现大量点击，包括
http://www.novell.com/support/kb/doc.php?id=7012851
无论如何，我目前根本不需要 cgroup，所以我只是禁用它：
sudo service cgconfig stop
现在一切都按预期进行。
编辑/etc/cgconfig.conf为了使更改在重新启动后持续存在，我还
必须注释掉内容。