我一直在使用 cset 来设置正在运行的进程的 CPU 亲和性。我正在使用 set 和 proc 手动重新创建内置的“shield”函数，以便为我的应用程序的特定线程添加一些子集。我有一个 bash 脚本，它调用 cset 来创建集合，并将正确的线程移动到正确的集合。它在与 sudo 一起运行时有效。
现在我想让另一个没有 sudo 权限的用户执行此脚本。我非常信任这个用户，相信他能负责 cset，但又不想公开 root 的广泛权限。
我认为脚本上的 CAP_SYS_NICE（sched_setaffinity 需要它，我只是假设 cset 必须使用它）就足够了，但那行不通。我尝试将 CAP_SYS_NICE 扩展到 cset 程序（它是 cset python 库的薄 python 包装器）。没有成功。我的 CAP_SYS_NICE 脚本上的 cap_to_text 输出是“=cap_ipc_lock,cap_sys_nice,cap_sys_resource+eip”（它有 ipc_lock 和 sys_resource 是出于其他原因；我认为只有 sys_nice 是相关的）。
有任何想法吗？
答案1
而只需授予该用户受限的 sudo 权限即可运行该脚本，例如：
bob ALL=(root) NOPASSWD: /usr/local/bin/cset.sh
NOPASSWD:如果您希望用户使用密码进行身份验证，请删除。
答案2
我一直认为 cset 是 SuSE 工具。我在 EL5 的 RHEL 上用过它，但到了 EL6，cgroups是处理屏蔽的首选方法。
我可能会采用 sudo 路线，限制将用户进程放入屏蔽所需的特定命令的访问。
答案3
尽管 cgroups 似乎取代了 cset/cpusets（正如 ewwhite 所说），我还是继续使用旧方法，因为它更熟悉并且仍然有效。
对于权限问题，我的特定问题已通过首先使用 cset 在 /cpusets 内创建一棵树来解决，我sudo chown -R root:myusergroup /cpusets/mytree和使用它sudo chmod -R g+rwX /cpusets/mytree。之后， 中的用户myusergroup能够通过 在树内移动进程echo $MYPID >> /cpusets/mytree/subtree/tasks。不幸的是，如果没有所有 /cpusets 的完整权限，cset 似乎无法工作——我相信每次运行命令时它都会尝试重新读取整个 /cpusets 目录——所以我不得不求助于这种手动移动进程的方法。
我并不是说它是每个人的理想解决方案，但它最适合我的背景和情况。