Linux namespace 中 hostname 修改后宿主机为什么不变

在 Linux 里，hostname 不是一块所有进程共享的全局字符串。它属于调用进程所在的 UTS namespace。进程在新 UTS namespace 中把 hostname 改成 worker-a，同一 namespace 的进程会看到新值；仍在宿主机 UTS namespace 的 shell 继续看到原值，这正是隔离生效的表现。

所以“修改后宿主机为什么不变”的答案是：你改的是隔离空间里的 hostname，不是宿主机所属 UTS namespace 的 hostname。先看进程的 namespace 归属，再排查权限，不要先反复改字符串。

为什么改了 hostname，宿主机仍显示旧值

UTS 是 Unix Timesharing System 的缩写。Linux 的 UTS namespace 负责隔离 hostname 和 NIS domain name；hostname 命令最终读取或修改的，是当前进程所属空间里的值。宿主机 shell、容器里的 PID 1、通过 nsenter 进入的进程，可能分别站在不同的视图里。

用 unshare 看见一次完整的 UTS 隔离

下面的命令只展示关系，不需要把宿主机 hostname 改掉。unshare --uts 为子 shell 创建新的 UTS namespace；使用 --fork 让命令在子进程中运行，退出后隔离空间也随之结束。

# 在新的 UTS namespace 中启动子 shell，并保留交互观察窗口
sudo unshare --uts --fork --mount-proc bash

# 只修改当前 UTS namespace 的 hostname
hostname worker-a

# 当前隔离 shell 会看到 worker-a，退出后回到宿主机 shell
hostname
exit

# 宿主机 shell 读取自己的 UTS namespace，原值不会被子 shell 的修改覆盖
hostname

新空间创建时会先复制父空间的 hostname，所以刚进入时可能暂时显示和宿主机一样；真正产生差异的是后续的 hostname worker-a。这也是容器里常见的现象：容器名称或运行时配置只改变容器自己的 UTS 视图。

用 namespace inode 判断你到底站在哪里

只看两个终端里显示的字符串不够。对宿主机 shell 和目标进程分别查看 /proc/PID/ns/uts，括号中的 inode 相同，才表示它们加入了同一个 UTS namespace。

# 查看当前 shell 的 PID 与 UTS namespace 标识
echo "shell pid=$$"
readlink /proc/$$/ns/uts

# 替换成目标进程 PID，比较它与当前 shell 的 UTS inode
TARGET_PID=1234
readlink "/proc/$TARGET_PID/ns/uts"

# 进入目标进程的 UTS namespace，再读取它看到的 hostname
sudo nsenter -t "$TARGET_PID" -u hostname

nsenter -u 只切换 UTS namespace，不会自动切换 PID、mount 或 network namespace。这个细节很重要：你可能已经进入了目标的 hostname 视图，却仍然使用宿主机的文件系统和网络视图。

修改失败时先查权限，再查生命周期

如果命令报没有权限，不代表 UTS namespace 没有创建成功。sethostname(2) 要求调用者在与该 UTS namespace 关联的 user namespace 中具备 CAP_SYS_ADMIN。非特权容器、未授予相应能力的进程，通常只能读取 hostname，不能修改它。

另一个常见误区是把临时 namespace 当成永久配置。unshare 启动的子 shell 退出后，里面的 hostname 修改就没有可继续观察的进程；容器则由运行时在创建阶段决定 UTS 设置。要让服务长期使用固定名称，应把设置放进容器运行参数或服务管理配置，并明确它作用在哪个 namespace。

常见问题

新 UTS namespace 会立刻得到一个空 hostname 吗？

不会。通过 clone 或 unshare 创建时，hostname 会从调用者的 UTS namespace 复制一份，之后才独立变化。

为什么两个进程都显示同一个 hostname，却不一定在同一空间？

因为新空间初始值可能与父空间相同。要判断归属，应比较 /proc/PID/ns/uts 的 inode，而不是只比较字符串。

nsenter 进入后改名会影响宿主机吗？

只有当 nsenter 进入的是宿主机 UTS namespace，且调用者有足够权限，修改才会影响宿主机视图；进入容器或其他隔离空间时不会反向传播。

排查顺序可以固定为：先比较 UTS namespace inode，再确认目标进程和 namespace 仍然存在，最后检查 CAP_SYS_ADMIN。这样就能把“宿主机没变”从异常现象还原为清晰的隔离边界。