Linux 运维工程师面试题精选（一）：基础知识与系统原理
基础题最能看出候选人是"会敲命令"还是"懂原理"。这一组题目覆盖文件系统、权限、进程、服务管理、存储和日志等日常工作中绕不开的知识点，每道题都给出结论、关键要点和常用命令，适合面试前系统过一遍，也适合面试官拿来做提问提纲。
本文题目一览
- 问题 1：inode 是什么？磁盘空间没满却无法创建文件是怎么回事
- 问题 2：软链接和硬链接有什么区别
- 问题 3：文件权限怎么读？ACL 和普通权限有什么不同
- 问题 4：SUID、SGID、Sticky Bit 分别有什么作用
- 问题 5：进程和线程有什么区别
- 问题 6：僵尸进程和孤儿进程是怎么产生的，如何处理
- 问题 7：systemd 里 service 和 target 是什么关系
- 问题 8：LVM 的结构是怎样的，在线扩容怎么做
- 问题 9：free 命令的输出怎么看，buff/cache 占的内存要不要担心
- 问题 10：cron 和 systemd timer 有什么区别，生产上更推荐哪个
- 问题 11：SSH 密钥登录的原理是什么，登录失败常见原因有哪些
- 问题 12：sudo 授权怎么配，怎么避免给过大的权限
- 问题 13：ulimit 里的文件句柄限制改了为什么不生效
问题 1：inode 是什么？磁盘空间没满却无法创建文件是怎么回事
结论：inode 是文件系统中记录文件元数据（权限、属主、大小、时间戳、数据块指针）的索引节点，文件名只是指向 inode 的一条目录项。df 显示有剩余空间却报 "No space left on device"，十有八九是 inode 耗尽，典型元凶是海量小文件。
- 查看 inode 使用率：
df -i，看 IUse% 是否打满 - 定位小文件目录：
find /var -xdev -type f | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head，或逐层du --inodes - 高发场景：会话文件目录、邮件队列、缓存目录、未清理的日志碎片
- 追问方向：inode 数量在 mkfs 时就基本定死，大文件为主的分区可适当调小 inode 密度，小文件场景则要调大
问题 2：软链接和硬链接有什么区别
结论：硬链接是多个文件名指向同一个 inode，本质是同一个文件的多个入口；软链接是独立文件，内容存的是目标路径，相当于快捷方式。
- 硬链接不能跨文件系统、不能指向目录；软链接两者都可以
- 删除原文件：硬链接只要还有一个入口，数据就在；软链接会变成断链（悬空链接）
- 判断方法：
ls -li看 inode 号，硬链接的 inode 相同且链接数大于 1 - 创建命令：
ln 源 目标建硬链接，ln -s 源 目标建软链接 - 追问方向：为什么硬链接不能指向目录——避免目录环路导致遍历死循环
问题 3：文件权限怎么读？ACL 和普通权限有什么不同
结论：传统权限按属主、属组、其他人三组 rwx 控制，粒度到"组"为止；ACL（访问控制列表）可以给任意指定用户或组单独授权，解决"只给某一个人加权限"的需求。
ls -l输出末尾有+号说明该文件设了 ACL，用getfacl 文件查看- 设置示例：
setfacl -m u:zhangsan:rx /data/report，目录继承用d:默认 ACL - 注意 mask 会影响实际生效权限，
getfacl里显示的 effective 才是真实权限 - 常见坑：某些文件系统要挂载时带 acl 选项（现代发行版 ext4/xfs 默认支持）；复制文件时 ACL 需
cp -a或rsync -A才能保留
问题 4：SUID、SGID、Sticky Bit 分别有什么作用
结论：三个特殊权限位各管一件事——SUID 让程序以文件属主身份运行，SGID 让程序以属组身份运行或让目录内新建文件继承目录属组，Sticky Bit 限制共享目录里只能删自己的文件。
- SUID 典型例子：
/usr/bin/passwd，普通用户借 root 身份改自己的密码，权限位显示为rws - SGID 用在协作目录：
chmod 2775 /data/team，组员新建文件自动归属团队组 - Sticky 典型例子：
/tmp的rwt，人人可写但互删不了对方文件 - 安全追问：排查提权风险时用
find / -perm -4000 -type f盘点 SUID 文件，异常多出来的要警惕
问题 5：进程和线程有什么区别
结论：进程是资源分配的基本单位，有独立的地址空间和文件描述符表；线程是调度的基本单位，同一进程内的线程共享地址空间和打开的文件，各自只有独立的栈和寄存器。
- 在 Linux 里线程本质是共享资源的进程（轻量级进程 LWP），由 clone 时的共享标志决定共享什么
- 查看线程：
top -H、ps -T -p <PID>、ls /proc/<PID>/task - 进程间通信（管道、信号、共享内存、socket）与线程间同步（锁、条件变量）是两套东西，不要混答
- 追问方向：多线程程序一个线程崩溃为什么整个进程退出——共享地址空间，非法内存访问触发的信号是进程级的
问题 6：僵尸进程和孤儿进程是怎么产生的，如何处理
结论：子进程退出后，父进程还没调用 wait 回收，子进程就只剩一张进程表项，称为僵尸进程（状态 Z）；父进程先退出，子进程被 init/systemd（PID 1）收养，称为孤儿进程，孤儿进程是正常现象、无害。
- 僵尸进程不占内存和 CPU，只占一个 PID 名额；大量堆积会耗尽 PID，先用
ps aux | awk '$8 ~ /Z/'定位，再往上找它的父进程 - 处理办法：不能直接 kill 僵尸（它已经死了），只能处理父进程——让父进程回收，或重启/终止父进程，由 PID 1 接管并回收
- 根因一般是父进程代码没处理 SIGCHLD 或没调用 wait，属于程序缺陷，运维侧只能临时止损
- 容器场景要注意：容器里 PID 1 若是不回收子进程的应用，会堆满僵尸，需用 --init 或 tini 这类 init 进程
问题 7：systemd 里 service 和 target 是什么关系
结论：service 是具体的服务单元，target 是一组单元的逻辑集合，相当于 SysV 时代的运行级别，用来定义"系统启动到什么阶段、拉起哪些服务"。
- 常用命令：
systemctl get-default看默认 target，systemctl isolate multi-user.target切换 - 服务开机自启的本质：enable 时按 unit 里 [Install] 的 WantedBy 在对应 target 的 .wants 目录建软链接
- 依赖语义要分清：After 只管顺序不管依赖，Wants 是弱依赖，Requires 是强依赖（对方失败自己也失败）
- 排查启动慢：
systemd-analyze blame和systemd-analyze critical-chain
问题 8：LVM 的结构是怎样的，在线扩容怎么做
结论：LVM 自底向上是 PV（物理卷）→ VG（卷组）→ LV（逻辑卷），文件系统建在 LV 上。扩容就是往 VG 里加空间（新 PV 或扩原 PV），再扩 LV，最后扩文件系统，三步缺一不可。
- 扩 LV 并同步扩文件系统：ext 系用
lvextend -r -L +50G /dev/vg0/data，-r会自动调用 resize2fs；xfs 用xfs_growfs 挂载点 - 关键前提：xfs 只能扩不能缩；ext 缩容必须先卸载并做文件系统检查，生产上一般只扩不缩
- 云盘场景常见流程：云上扩盘 →
pvresize让 PV 认新容量 → lvextend → 扩文件系统 - 追问方向：LVM 快照的写时复制原理和注意事项——快照空间写满会失效，不能当备份用
问题 9：free 命令的输出怎么看，buff/cache 占的内存要不要担心
结论：看 available 一列，那才是"不动 swap 就能给应用用的内存估算"。buff/cache 是内核拿空闲内存做的页缓存和缓冲，应用需要内存时会自动回收，不用手工 drop。
- free = total - used - buff/cache，真正紧张的信号是 available 持续走低并开始用 swap
- buffer 缓存的是块设备元数据，cache 缓存的是文件页内容，两者现在合并统计为 buff/cache
echo 3 > /proc/sys/vm/drop_caches只适合做基准测试前的清场，生产上执行只会让缓存冷掉、性能变差，是减分回答- 更细的观察看
/proc/meminfo和vmstat 1的 si/so（换入换出速率）
问题 10：cron 和 systemd timer 有什么区别，生产上更推荐哪个
结论：cron 简单通用但功能止于"按时拉起"；systemd timer 与服务单元一体，能管依赖、随机延迟、错过补跑和统一日志，新系统上更推荐 timer，老脚本平滑迁移仍可用 cron。
- timer 的关键能力：OnCalendar 定义时间，Persistent=true 让关机错过的任务开机补跑，RandomizedDelaySec 把整点任务打散
- cron 的经典坑：环境变量与交互 shell 不一致（PATH 很短）、% 在 crontab 里要转义、任务重叠执行没有互斥
- 日志排查：cron 任务看
/var/log/cron和邮件，timer 直接journalctl -u 服务名 - 防重入无论用哪个都要自己加：
flock -n /run/job.lock是最稳妥的做法
问题 11：SSH 密钥登录的原理是什么，登录失败常见原因有哪些
结论：原理是非对称加密的挑战应答——服务器用公钥加密一段随机数据，客户端只有用配对的私钥能解开，私钥从不经过网络。登录失败大多不是密钥错，而是权限和归属问题。
- 权限红线：家目录不可被组/他人写，
~/.ssh为 700，authorized_keys为 600，否则 sshd 的 StrictModes 会直接拒绝 - 排查顺序：先看服务端日志
journalctl -u sshd或/var/log/secure，客户端用ssh -vvv看走到了哪一步 - 其他常见原因：authorized_keys 里公钥被编辑器折行、登录用户被 AllowUsers/DenyUsers 限制、服务端只允许公钥而客户端还在尝试密码（或反过来）
- 安全加固追问：关密码登录（PasswordAuthentication no）、禁 root 直登、改端口只是降噪不是安全措施，真正的措施是密钥 + 跳板机 + fail2ban 类限流
问题 12：sudo 授权怎么配，怎么避免给过大的权限
结论：sudoers 遵循最小权限原则——按"谁、在哪些主机、以什么身份、能执行哪些命令"逐条授权，能给命令白名单就绝不给 ALL，能用命令别名分组管理就不要逐人写。
- 必改习惯：永远用
visudo编辑，它会做语法校验，写错不至于把自己锁在门外；单人单文件放/etc/sudoers.d/ - 典型授权：
ops ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/journalctl，只放行具体动作 - 大忌：
NOPASSWD: ALL、给 vim/less/shell 类命令的 sudo（可直接逃逸出 shell 等于 ALL） - 审计：sudo 默认把执行记录打进日志，可用
grep sudo /var/log/secure复盘谁执行过什么
问题 13：ulimit 里的文件句柄限制改了为什么不生效
结论：因为句柄限制是分层生效的——有系统级上限（fs.file-max）、会话级限制（limits.conf/PAM）和进程继承关系，改的地方不对、或服务不是从你改的那个会话起的，就不会生效。
- 先分清软硬限制：
ulimit -n看软限制，ulimit -Hn看硬限制，普通用户只能在硬限制内调软限制 - limits.conf 只对经 PAM 的登录会话生效，对 systemd 拉起的服务无效——服务要用 unit 里的
LimitNOFILE= - 判断某进程实际限制：
cat /proc/<PID>/limits | grep "open files"，这是最可靠的验收方法 - 追问方向：限制调到百万级还要考虑 fs.file-max 和单进程内存开销，不是越大越好
面试官视角
这一组考的是基础是否"成体系"：能不能把 inode、进程、权限这些概念讲清原理，并落到具体命令上。回答时先给结论、再讲机制、最后给一条验证命令的候选人，通常基础比较扎实；只会背命令说不出"为什么"、把 drop_caches 当日常操作、把僵尸进程说成"kill 掉就行"的，是明显的经验断层。加分项是主动提到边界条件——比如 limits.conf 对 systemd 服务不生效、xfs 不能缩容、cron 与登录环境不一致——这类细节只能从真实踩坑中来，背题背不出来。
