【Ubuntu中合并cgroup挂载点失败】报错:mount: none is already mounted or /cgroup/cpu busy

本文介绍如何解决Ubuntu系统中合并cgroup挂载点的问题,通过修改systemd配置文件,实现cpu,cpuacct,cpuset三个子系统的挂载合并。

问题

有时候我们可能会遇到需要修改系统默认cgroup挂载点的情况,例如需要把cpu,cpuacct,cpuset挂载到一起的情况,但是有些操作系统(目前知道Ubuntu会出现这种问题)如果直接使用下面方法合并挂载cgroup的时候可能会遇到下面这种报错。
cgroup挂载失败
具体原因目前无法得知,很可能的原因是不同的操作系统版本限制。
但是我们可以换另外一种方式解决这个问题。

猜想

cgroup默认挂载是由systemd去划分挂载的,那么systemd的配置文件(/etc/systemd/system.conf)中应该也有相应的配置。查阅资料后发现确实如此。
点击查看ubuntu官方文档
官方文档中描述如下:
systemd中cgroup相关配置
默认配置中cpu,cpuacct和net_cls,netprio这四个子系统为两两合并挂载,所以默认挂在方式就是我们所看到的下面这种:
cgroup默认挂载

验证

现在我们需要把cpu,cpuacct,cpuset挂载到一起,那么我们需要修改/etc/systemd/system.conf中JoinControllers中配置项。如下图所示。
system.conf配置
接着reboot,再查看cgroup挂载点,已被修改为cpu,cpuscct,cpuset的形式。
在这里插入图片描述

<think>好的,我现在需要解决用户遇到的“mounting cpu_group failed: Invalid argument”错误。首先,我要理解这个错误发生的背景。用户可能在尝试挂载cgroup子系统,特别是CPU子系统时遇到了问题。根据用户提供的引用内容,例如引用[2]中提到v4环境中如果存在/cgroup/cpu/路径会导致服务重启失败,这可能与cgroup的版本有关。 首先,我需要确定用户使用的cgroup版本。因为cgroup v1和v2在挂载方式上有差异。在v1中,每个子系统(如cpu、memory)需要单独挂载,而v2使用单一统一层次结构。如果用户混合使用两种版本的挂载方式,可能会导致冲突,从而出现无效参数的错误。 接下来,检查挂载的路径是否正确。引用[3]提到创建cpu subsys的cgroups,可能在v1中需要正确指定子系统类型。如果挂载命令中子系统类型错误,比如误写为cpu_group而不是cpu,就会导致失败。用户提到的错误信息中的“cpu_group”可能是一个拼写错误,正确的应该是cpu。 然后,考虑内核是否支持对应的子系统。如果内核编译时未启用cgroup CPU子系统,挂载时会失败。用户可以通过检查/proc/cgroups文件中的cpu条目是否存在,并确认是否已启用。引用[3]中提到从/proc/cgroups查询子系统,所以这一步很重要。 另外,挂载路径的权限问题也可能导致错误。确保挂载目录存在,并且有适当的权限。如果目录不存在,需要先创建;如果权限不足,可能需要使用sudo或者调整目录权限。 还有可能与其他已挂载cgroup冲突。例如,在v2中已经挂载了统一层次结构,再尝试挂载v1的子系统会导致错误。引用[2]指出在v4环境中存在旧路径可能导致失败,所以需要清理旧的挂载。 最后,检查挂载命令的语法是否正确。正确的v1挂载命令应该是“mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct”。如果参数顺序或选项错误,系统会返回无效参数错误。 综合这些可能性,我需要逐步引导用户检查cgroup版本、子系统状态、挂载、权限以及命令语法,从而找到具体原因并解决。</think>### 导致 "mounting cpu_group failed: Invalid argument" 的常见原因及解决方案 #### 1. **cgroup 版本不兼容** - **原因**: 系统可能已默认使用 cgroup v2,但尝试以 v1 的方式挂载子系统(如单独挂载 `cpu`)。cgroup v2 要求以统一层级结构挂载,不支持单独挂载子系统[^2]。 - **验证方法**: ```bash cat /proc/filesystems | grep cgroup ``` 若输出包含 `cgroup2`,则系统默认使用 v2。 - **修复方案**: - **方法1**: 切换到 cgroup v1 在启动参数中添加 `systemd.unified_cgroup_hierarchy=0`,例如修改 `/etc/default/grub` 中的 `GRUB_CMDLINE_LINUX`: ```bash GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0" ``` 更新配置后重启系统。 - **方法2**: 清理冲突挂载 若存在残留的旧挂载路径(如 `/cgroup/cpu`),需先卸载并删除目录: ```bash umount /cgroup/cpu 2>/dev/null rm -rf /cgroup/cpu ``` #### 2. **子系统名称错误** - **原因**: 使用错误子系统名称(如 `cpu_group` 而非 `cpu`)。cgroup v1 的 CPU 子系统名为 `cpu`,需搭配 `cpuacct` 使用[^3]。 - **修复方案**: 正确挂载命令应为: ```bash mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct ``` #### 3. **内核未启用 CPU 子系统** - **原因**: 内核编译时未启用 `CONFIG_CGROUP_SCHED` 或 `CONFIG_CGROUP_CPUACCT`。 - **验证方法**: ```bash cat /proc/cgroups | grep cpu ``` 若输出中 `cpu` 和 `cpuacct` 的 `enabled` 列为 `0`,则子系统未启用。 - **修复方案**: 重新编译内核并启用以下选项: ```config CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_CPUACCT=y ``` #### 4. **挂载路径权限问题** - **原因**: 挂载目标目录不存在或权限不足。 - **修复方案**: ```bash mkdir -p /sys/fs/cgroup/cpu,cpuacct chmod 755 /sys/fs/cgroup/cpu,cpuacct ``` #### 5. **与其他 cgroup 配置冲突** - **原因**: 系统服务(如 `systemd` 或 `cgconfig`)已管理 cgroup 配置,导致手动挂载冲突。 - **修复方案**: 停止相关服务后再挂载: ```bash systemctl stop cgconfig.service mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct ``` --- ### 操作验证流程 1. **检查 cgroup 版本** ```bash stat -fc %T /sys/fs/cgroup/ ``` - 输出 `cgroup2fs` 表示 v2,`tmpfs` 表示 v1。 2. **验证子系统状态** ```bash grep -E 'cpu|cpuacct' /proc/cgroups ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值