这一篇是Linux常用命令系列的第六篇。写下这个标题的时候我突然意识到这个系列已经被办公室同事当成了一本“应急小册子”在用。前几篇我们聊过文件、文本处理和基础网络这一篇我想换个角度不按命令字典的路子来而是按“问题现场”来讲你在排查用户权限、进程状态、日志异常、存储挂载和容器工具时究竟应该敲哪些命令为什么要敲这些命令踩过坑之后还能怎么补救。这个定位更适合两类人一是刚转运维或开发需要快速建立一套排查思路的同学二是被生产环境反复折腾过但缺少系统整理的老手。命令这东西背是背不完的真正值钱的是你脑子里那条“先看什么、再看什么、最后怎么办”的链路。1. 用户与会话别等权限出问题再回头补课1.1 新建用户的三个细节家目录、Shell和sudo新手最典型的一个坑就是用useradd建完用户切过去发现连家目录都没有。原因很简单CentOS/RHEL 系的useradd默认不会创建家目录除非你显式加了-m。正确的姿势大概是这样的sudo useradd -m -d /home/zhang -s /bin/bash zhang sudo passwd zhang sudo usermod -aG sudo zhang这里每个参数都不是摆设。-d指定家目录路径如果你不写默认会按/home/用户名来-s指定登录 Shell系统默认可能是 sh进去以后方向键、补齐和历史记录都别扭所以除非有特殊需求我统一用/bin/bash。-m的意思是同时创建家目录并且把/etc/skel里的模板文件复制进去像.bashrc、.profile这些初始配置都是这么来的。再强调一个容易忽略的细节useradd -D可以查看当前系统创建用户的默认值包括默认 Shell、家目录基准路径、默认用户组策略。批量上线账号前先执行一下这条命令能提前发现“为什么所有人建出来都是 nologin Shell”之类的幺蛾子。sudo 授权也有讲究。Debian/Ubuntu 系的发行版通常用sudo这个用户组而 CentOS 系用的是wheel。最常见的问题是明明把用户加进了组却依然无法 sudo很可能是改错了组名或者用了usermod -G而不是usermod -aG。-G会直接覆盖用户的附加组列表不加-a等于把用户之前加入的所有补充组全部清空轻则权限缺失重则连 docker 组、dev 组都没了。所以我的习惯是凡是追加组永远写全-aG。另外一个安全习惯是不要直接用vim /etc/sudoers去改文件除非你想被语法错误锁死。正确操作是visudo它会在保存前做语法检查。如果你要给某个用户特别权限建议在/etc/sudoers.d/下建一个独立文件比如echo zhang ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx | sudo tee /etc/sudoers.d/zhang-nginx sudo visudo -c生产环境尽量别用NOPASSWD: ALL那样和把一个 root 口令贴在工位上没什么区别。1.2 停用、锁定和删除删用户不是按个回车删除用户最干净的方式是userdel -r-r会连家目录和邮件池一起删。但在生产环境里我吃过一次亏有一个服务用 systemd 的Userdaemon跑着我直接删了那个用户结果一堆文件变成了数字 UID 所有排查了半天才反应过来。所以删除之前先查一下这个用户是否还有进程在跑ps -u olduser -o pid,cmd pkill -u olduser如果确认要删还建议先把家目录打个包再执行删除万一里面有配置文件和脚本后悔药还有得吃。另外运维审计要求不能删账户而必须锁账户时可以用sudo passwd -l olduser sudo usermod -L olduser两条命令都能让账户无法登录但侧重点略有不同。passwd -l是给密码字段加锁而usermod -L是直接锁定用户。真正常被忽略的是这两个操作都只影响后续登录已经建立的会话不会马上被踢掉。如果你需要立刻踢人还得配合pkill -u olduser或loginctl terminate-user olduser。顺带说一句lastlog和last前者能看每个用户最后登录时间后者看登录历史记录包括重启时间点。排查“谁半夜动过服务器”基本都是靠这两个命令起手。1.3 会话和后台运行别再用 nohup 硬扛了看当前系统上有谁在线我一般用w它能显示登录用户、终端、来源 IP、当前在跑什么命令比单纯的who信息全。需要看历史登录记录用last需要看失败登录记录要用lastb这个命令需要 root 权限。后台运行工具这块很多人一说就是nohup command 。说实话nohup 能解决“终端关闭后进程不退出”的问题但它解决不了“会话丢了就找不回来”的问题。如果任务是编译、数据同步、压测这种需要持续盯着的活我更推荐tmuxtmux new -s task # 跑你的命令然后 CtrlB 再按 D 脱离会话 tmux attach -t task为什么推荐它因为 tmux 把会话和服务端绑在一起就算你 SSH 断开、本机网络抖动会话里的进程也不会被 SIGHUP 带走下次连上去直接tmux attach就能接着看。nohup 能做的它都能做还能多窗口、分屏、日志回看。如果是临时起一个进程也可以考虑setsid command它会创建新的会话并脱离终端控制但操作体验和回看能力都不如 tmux。我的建议是一次性任务用 nohup需要长期跟踪的任务一律 tmux。1.4 口令策略和过期提醒密码过期这事其实挺容易踩坑。你以为设置了过期时间系统就会在用户登录时提醒但实际上很多环境里用户根本收不到提示因为他们用的密钥登录根本不会走到密码验证那一步。常见操作是把这三条配合起来sudo chage -M 90 zhang # 密码最长使用 90 天 sudo chage -W 7 zhang # 过期前 7 天开始警告 sudo chage -d 0 zhang # 强制下次登录改密码查看用户当前密码有效期用chage -l zhang清理临时账号也可以用chage -E 2025-12-31 zhang给它加一个失效日期。我自己写巡检脚本时会给所有用户循环执行chage -l再配合lastlog输出基本能覆盖大多数账户合规需求。2. 进程与资源用命令拼凑一张“现场图”2.1 别把 ps 当“拍一下照片”ps是最常用的进程查看命令但很多人只会ps -ef然后瞪眼找。我先说两个固定的看点ps -ef输出里PPID是指父进程 IDC是 CPU 使用率ps aux输出里%CPU、%MEM、VSZ、RSS这些字段非常直白RSS 是物理内存占用VSZ 是虚拟内存。排查内存泄漏时我会先用ps aux --sort-%mem | head把内存占用 Top10 拎出来。再一个是过滤技巧。直接ps -ef | grep nginx经常会带出那条 grep 自身的进程很碍眼。更稳的办法是用pgreppgrep -f nginx: worker-f表示匹配完整命令行而不仅仅是进程名。这在过滤脚本类进程时尤其有用比如pgrep -f python.*app.py。但注意-f匹配的是整个命令行如果命令行里包含特殊字符且不带引号容易把自己 bash 的历史命令也匹配出来所以使用前最好先用ps -eo pid,cmd | grep ...验证一下。2.2 top 的批处理模式和 load average 怎么读交互式top我基本只在临时看两眼的时候用真正写进脚本和排查记录里的是批处理模式top -bn1 -o %MEM | head -20-b是批处理不刷屏-n1只采样一次-o %MEM按内存排序等价于交互界面按大写 M。按 CPU 排序用-o %CPU只看某个进程用top -p PID只看指定用户用top -u zhang。很多人对 load average 的理解是有偏差的。load average: 5.8, 3.2, 2.0分别表示 1 分钟、5 分钟、15 分钟的平均活跃进程数。但如果机器是 8 核5.8 并不算高反而说明有约 2 个核的空闲如果是 4 核5.8 就已经超载了。更重要的是load 高不一定代表 CPU 忙还有可能是大量进程进入了不可中断的D状态比如 NFS 挂载失联、磁盘 IO 卡死。这时候 CPU 使用率可能很低但系统已经处于半瘫痪状态。所以看到 load 高先top看一眼排前面的进程状态是 R 还是 D再往下查。2.3 进程启动时间和“进程名对不上号”的问题排查“这个服务到底什么时候被重启过”最直接的是这条ps -p PID -o pid,lstart,etime,user,cmdlstart是进程启动的绝对时间etime是已经运行了多久。配合最近的上线记录或定时任务日志基本就能对上号。但这里有个高级一点的坑Linux 进程名是可以被修改的。服务本身可以通过prctl(PR_SET_NAME)改自己的 comm 字段启动脚本也可以用exec -a custom_name ./your_binary把 ps 显示的名字改成别的。所以常在 ps 里看到一个进程叫myserver但它实际跑的是一个叫backup_agent.so的动态库程序。识别真实程序的办法很简单readlink -f /proc/PID/exe这条命令能告诉你这个进程真正执行的二进制文件路径比看 ps 输出靠谱得多。排查可疑进程时/proc/PID/exe、/proc/PID/cwd、/proc/PID/environ这三个文件是必看的。2.4 僵尸进程kill -9 治不了的病僵尸进程的标志是在ps输出里状态那列显示Z命令行最后带着defunct。它的本质是子进程已经退出但父进程没有调用 wait 回收它的退出状态。所以kill -9对僵尸进程完全无效——它不是活着的进程你杀不掉一个已经死了的进程。定位僵尸进程可以这样ps -A -o stat,ppid,pid,cmd | awk $1 ~ /^Z/拿到 PPID 后往上看这个父进程是什么父进程如果没有异常就让它自己回收如果父进程卡住了通常要重启或干掉父进程让僵尸变成孤儿被 init 收养再由 init 统一回收。生产环境里我见过大量僵尸集中在某个宿主机底层原因多半是容器里的 PID 1 进程没有正确处理子进程退出信号或者 Java 程序的父进程没有 wait。这种问题在容器监控里非常典型需要应用层面配合处理而不是在操作系统层面硬杀。2.5 资源限制连接数上不去先查 ulimit高并发场景下最常见的报错是 Too many open files。这跟文件描述符fd上限有关默认值在多数系统上是 1024对 web 服务来说远远不够。查看当前限制和给指定进程设置限制的方法ulimit -n ulimit -n 65535永久修改通常写在/etc/security/limits.conf或/etc/security/limits.d/下* soft nofile 65535 * hard nofile 65535不过要注意区分 soft 和 hardsoft 是当前会话可以自行提升到的上限hard 是硬性天花板。修改后必须重新登录或重启服务才生效这也解释了为什么很多同事改了 limits.conf 以后跑起来的进程仍然报 1024。验证进程实际生效值可以查cat /proc/PID/limits排查 fd 占用数量用lsof -p PID | wc -l如果这个数字持续上涨且不回落基本可以断定是哪里连接没有释放顺着 lsof 的输出继续查 FD 类型就行。3. 日志检索把 tail、grep、awk 串成一条流水线3.1 grep 的正确姿势上下文、边界和二进制从日志里捞有效信息第一反应是 grep但很多人只会grep error app.log。我要补几个常用姿势grep -E ERROR|timeout|deadlock app.log | head -50 grep ProductAPI access.log -A 2 -B 2 grep -w 404 access.log-A 2 -B 2是显示匹配行的前后 2 行这个在查堆栈和异常上下文时简直是救命稻草。-w是单词边界匹配避免你把404和4040混在一起。-E是多条件或正则匹配比写好几个管道再合并干净得多。还有一个非常烦人的问题是二进制文件。日志文件里混进了少量 \0 字节grep 就会输出Binary file app.log matches结果什么都看不到。解决办法是加-a或--text强制按文本处理。递归搜索日志目录时我建议直接用grep -rn --include*.log ERROR /var/log/app/3.2 按时间段抽取sed 和 awk 的分工日志定位最常遇到的问题就是“这五分钟之内到底发生了什么”。如果日志格式整齐每行开头是2025-02-01 12:30:00可以用 sed 按行范围切sed -n /^2025-02-01 12:30:00/,/^2025-02-01 12:35:00/p app.log但 sed 有个前提就是日志本身是按时间顺序排的。如果日志文件被多线程写、被切割合并过顺序乱了sed 这套就不靠谱了。更通用的做法是用 awk 对字段进行比较awk /^2025-02-01/ $2 12:30:00 $2 12:35:00 app.log这里假设$1是日期、$2是时间字段分隔符是空格。如果日期格式不是标准开头可以先用 grep 粗筛再用 awk 精切。我处理 10GB 大日志时经常是先grep 2025-02-01 big.log day.log把文件拉到 GB 级别以内后面 sed 和 awk 的速度才会理想。3.3 统计与去重sort uniq 才是完整搭档想分析访问日志里哪些 IP 最活跃最简单的流水线是cut -d -f1 access.log | sort | uniq -c | sort -rn | head -10这段命令的意思是用 cut 切出 IP 列sort 排序让相同 IP 挨在一起uniq -c 统计次数再按次数倒序取前 10。很多人只用uniq就发现统计不对那是因为 uniq 只会合并相邻的重复行不先 sort 的话相同 IP 分散在文件各处根本合并不到一起。统计 HTTP 状态码分布同理awk {print $9} access.log | sort | uniq -c | sort -rn如果是四段式 nginx 日志状态码字段在第 9 列如果是其他格式可以先head -1 access.log确认字段位置。这套组合我每天都在用跑完一眼就能看出 5xx 是否激增。3.4 实时追踪tail -F 和 tail -f 不是一回事看日志实时输出用tail -f没错但生产环境里日志经常按天轮转比如 nginx 的 access.log 会被 rename 成 access.log.20250201再新建一个 access.log。这时候你原来的tail -f还在盯着旧文件的 fd新日志进来你完全看不见。正确做法是tail -F /var/log/app/app.log大写 F 会按文件名追踪文件被轮转后会重新打开新文件。这个坑我踩过不止一次排查了半小时才发现日志一直没滚动问题不在程序而在 tail 的参数。配合管道过滤可以这样tail -F app.log | grep --line-buffered ERROR如果用的是 systemd 管理的服务直接看 journal 更省事journalctl -u my-service -f --since 1 hour ago journalctl -u my-service --since 2025-02-01 12:30:00 --until 2025-02-01 12:35:003.5 大日志文件别用 catless 才是阅读利器我总是跟新人说看到一个 5GB 的日志千万别cat。正确工具是lessless app.log打开后按/ERROR搜索n跳下一处N跳上一处按G跳到文件尾按g跳到文件头按F进入类似于 tail -f 的跟随模式CtrlC 中断跟随直接读压缩日志less app.log.gz甚至zcat app.log.gz | head -50。从这里你会发现一段好的排查思路其实就是 tail、grep、awk、sed、less 这几个命令的组合单拎出来都简单但组合起来能解决绝大多数日志问题。4. 网络与存储从连通性到挂载的排查套路4.1 端口与服务用 ss 替代 netstat排查“端口明明在监听为什么从外面连不上”我有一套固定顺序。先看端口是否在本地监听ss -tulnp | grep 8080-t看 TCP-u看 UDP-l只看监听-n不做域名反解-p显示进程信息避免用 netstat 还要等半天反向解析。接着看有没有进程占着端口lsof -i :8080如果监听正常再去验证对方能不能通nc -vz 192.168.1.10 8080-v显示详细过程-z表示只扫描端口不发送数据。如果 IP 能 ping 通但端口不通基本就是防火墙拦截检查顺序是firewall-cmd --list-all或iptables -L -n -v。这里我要提醒一点很多云主机的安全组规则是云平台层面控制的操作系统里 iptables 是空的那问题十有八九出在安全组别再反复重启服务了。处理建连数异常可以用 ss 统计ss -ant state established ( dport :443 ) | wc -l看 TIME_WAIT 状态的连接数量能帮你判断端口耗尽类问题。4.2 DNS 排查别忽略 systemd-resolved解析出问题时的排查路径一般是先手动解析目标域名再检查系统接入的 DNS 配置。手动解析用 digdig short www.example.comshort只输出 IP非常干净。nslookup 也可以但输出冗余我日常用 dig 更多。然后看/etc/resolv.conf确认 nameserver 指向哪里。如果你用的 Ubuntu 18.04 以上版本这个文件很可能是被 systemd-resolved 管理的手动改了以后重启网络又会被覆盖。查看实际生效的 DNS 状态resolvectl status清 DNS 缓存用resolvectl flush-caches很多“域名突然解析失败”的假故障其实是缓存了过期的 A 记录清一次缓存就好了。4.3 NFS 和 CIFS 挂载挂在墙上的不是命令是坑挂载 NAS 存储NFS 最常见的挂载格式sudo mount -t nfs4 -o rw,bg,hard,intr,noatime 192.168.10.5:/data /mnt/databg表示后台重试挂载失败时不会一直卡住终端hard是硬挂载intr允许中断这两个配合起来能让进程在 NFS 失联时可被 CtrlC 打断。如果你用的是软挂载softNFS 服务抖动时会直接给应用返回 IO 错误数据库之类的在线服务很容易写坏文件所以生产场景我一般倾向 hard。但是 hard 挂载最大的副作用是NFS 服务彻底失联时ls那个目录会一直卡住整个进程进入 D 状态连 kill -9 都没反应。所以重要目录的 fstab 条目一定要考虑是否加nofail。Windows/CIFS 共享挂载是另一套参数sudo mount -t cifs //192.168.10.20/share /mnt/share -o usernamebackup,passwordxxx,vers3.0,secntlmssp这里指定vers3.0是防止老版本协议协商失败或安全性过差。挂在/etc/fstab时有一个容易被忽略的选项是_netdev它告诉系统“这是网络设备等网络就绪后再挂载”不加它开机容易因为网卡没起来而挂载失败严重时会卡在启动流程。一个参考条目192.168.10.5:/data /mnt/data nfs4 defaults,_netdev,nofail,noatime,hard,intr 0 0写完之后先sudo mount -a验证语法再用findmnt --verify检查 fstab 内容。NFS 挂载信息查看nfsstat -m卸载不掉的挂载点用sudo umount -l /mnt/data-l是 lazy 卸载先把挂载点从目录树中摘除等 IO 结束后再真正收尾。这种操作适合 NFS server 已经失联的紧急情况。4.4 磁盘和 inodedf、du 之外还要会看 lsof磁盘排查最基础的是df -h和du -sh。但如果你发现df -h显示分区已满du -sh在对应目录统计出来的总量却对不上优先怀疑一件事有文件被进程删除但还没释放。Linux 下删掉的 open file 不会立刻释放空间只有进程关闭 fd 才能释放。查找这种“隐形大文件”lsof L1L1表示列出 link count 为 0 的被删文件看到 PID 和进程名后重启对应进程即可释放空间。inode 耗尽也是一种满表现是df -h还有空间但无法创建文件。用df -i查看 inode 使用率。如果确实被大量小文件塞满可以用find /data -xdev -type f -size 1G -exec ls -lh {} \; 2/dev/null-xdev限定不跨文件系统避免扫到挂载点深处把结果搞混。找大文件和清 inode 是两个完全不同的思路别混在一起。5. 绕不开的工具命令Docker、Redis、HDFS、GDB、ADB5.1 Docker日志、进容器、看资源占用容器环境下的常用命令已经变成了日常的一部分。我写几个最常用的docker ps -a docker logs -f --tail200 my-container docker exec -it my-container bash docker stats --no-stream docker inspect -f {{.NetworkSettings.IPAddress}} my-container docker top my-containerdocker logs --tail200避免直接把几千行日志打到终端docker inspect后面那串 Go 模板语法看着唬人实际上就是在取容器 IPdocker top能看到容器内进程在宿主机上的真实 PID排查资源问题时常需要它。不要用docker attach它和容器的主进程共享 stdin/stdout用的时候一按 CtrlC 很容易把容器也停掉。理由很简单attach是直接连主进程exec是开一个新的交互进程后者安全得多。5.2 Redis宁可慢也不要用 KEYS排查 Redis 问题先redis-cli ping确认还活着然后这几个命令轮流上redis-cli INFO memory redis-cli INFO stats redis-cli --scan --pattern cache:* | head -20 redis-cli SLOWLOG GET 10 redis-cli DBSIZE redis-cli TYPE user:10086INFO系列是诊断一切的入口内存、客户端连接数、命中率都在这。需要匹配大量 key 时用--scan --pattern千万不要用KEYS *因为 KEYS 会阻塞整个 Redis 实例在生产环境上等于自杀。慢查询日志SLOWLOG GET能看到耗时过久的命令再配合客户端 IP 去定位调用方是排查 Redis 性能问题最常见的一条线。5.3 HDFS大数据同学的大文件操作HDFS 和本地文件系统的命令风格很像但细节不同hdfs dfs -ls -R /data hdfs dfs -mkdir -p /user/zhang hdfs dfs -put local_file /user/zhang/ hdfs dfs -get /user/zhang/remote_file ./local_file hdfs dfs -du -h /user/zhang hdfs dfs -rm -r /user/zhang/tmp_dir hdfs dfs -tail /user/zhang/log.txt-du -h可以快速看目录下每个子目录的空间占用排查“哪个目录把磁盘吃完了”很好用。HDFS 对小文件非常不友好NameNode 会把每个文件、目录和 block 的元数据都放在内存里上百万个小文件直接能把内存吃光。所以新人在做数据采集时我建议先考虑合并写入而不是堆零散文件。如果已经积累了一批小文件可以用hdfs dfs -getmerge到本地再传回去或者在调度层用 coalesce 处理。5.4 GDB调试崩溃程序的最后手段GDB 看起来是 C/C 开发者的工具但运维在排查 core dump 时也离不开。最基本的流程gdb ./your_program core.12345 (gdb) bt (gdb) info registers (gdb) info threads (gdb) thread 2bt打印调用栈崩溃现场第一件事就是btinfo registers看寄存器值配合反汇编分析更细的问题。如果程序还在跑可以这样挂上去sudo gdb -p PID在 GDB 里执行continue让进程继续跑等到问题复现。需要注意两点一是对生产环境重要进程执行 gdb -p 会暂停进程虽然可以 continue但极短的停顿对在线服务也可能造成抖动尽量在低峰期操作二是让 core dump 能生成的话要先设置ulimit -c unlimited不要忘记检查 core 文件生成路径通过sysctl kernel.core_pattern查看。否则段错误程序跑崩了你四处找 core路径却指向 systemd-coredump 管理的目录白忙一场。5.5 ADB嵌入式开发调试的瑞士军刀在嵌入式、Android 或电视盒子类设备上调试ADB 是绕不开的。最常用的几组命令adb devices adb -s 设备序列号 shell adb shell logcat -s MyApp:I adb push ./app.apk /data/local/tmp/ adb reverse tcp:8080 tcp:8080 adb install -r app.apk adb kill-server多设备同时插在电脑上时直接adb shell会报错提示有多台设备必须加-s选设备序列号。adb reverse的作用是把设备上的端口映射到本机调试 Web 页面时很实用。设备连不上时先怀疑 adb server 状态执行adb kill-server再重新adb devices一般能解决。这几个命令虽然不属于服务器运维核心但做 Linux 系统的嵌入式方向完全离不开。6. 现场问题速查记录我踩过的那些坑6.1 tail -f 看不到新日志现象日志文件确实在更新但tail -f不输出。原因日志轮转工具把 access.log 改名tail 还抱着旧文件的 fd。解决改用tail -F。这是我列为“新人必踩第一名”的坑没有任何例外情况。6.2 grep 命中但显示 Binary file matches原因文件中有 \0 字节grep 判定为二进制。解决加-a强制文本模式或者用--include*.log先过滤再搜。不要因为这个问题就加-r盲目扫描范围越大越容易被二进制文件干扰。6.3 ps 看到的进程名完全对不上二进制原因进程用prctl或启动脚本用exec -a改了 argv[0]。解决用readlink -f /proc/PID/exe看真实路径。排查恶意进程或“看不懂的异常进程”时这条是杀手锏。6.4 /etc/fstab 写错导致开机进 emergency mode现象重启后系统停在 emergency mode。原因fstab 里某条挂载配置错误文件系统挂载失败。解决输入 root 密码进入维护模式注释掉或修正错误行然后mount -a验证。预防修改 fstab 之前先备份改完用findmnt --verify检查语法。6.5 NFS 失联所有进程呈 D 状态kill 不掉现象load average 飙升ps 里大量 D 状态进程。原因NFS server 宕机或网络中断硬挂载的进程阻塞在 IO 上。解决先恢复网络或 NFS 服务再用umount -l摘除挂载点实在不行重启对端服务。在线事务型应用不要把核心数据目录直接放 NFS集群文件系统另选方案。6.6 新建用户无法 sudo现象用户明明在 sudo 组却提示 not in the sudoers file。原因要么组名不对Ubuntu 是 sudoCentOS 是 wheel要么usermod -G覆盖了原由的附加组。解决确认发行版默认 sudo 组使用usermod -aG 组名 用户并visudo -c校验。下面这张速查表是我贴在工位上的一份常用对照适合打印出来现象典型命令补充说明端口被占用ss -tulnp优先用 ss不用 netstat哪个目录占空间du -h --max-depth1配合 sort -h 看从大到小文件删了空间没释放lsof L1找被删除但仍打开的文件日志只追新不追旧tail -F处理轮转日志必须用大写 F进程真实路径readlink -f /proc/PID/exe比 ps 输出更可靠容器内看宿主机进程docker top不要只在容器里看 ps分析访问日志 Top IPcut -d -f1 log | sort | uniq -c | sort -rn必须先 sort 再 uniq我个人在这些命令上花的冤枉时间不算少所以最后再分享一个小习惯不要试图把命令背全而是围绕“问题类型”去建自己的速查脚本。比如我会在~/.bashrc里放几个 aliasalias portsss -tulnp、alias du1du -h --max-depth1 | sort -h、alias zzps -A -o stat,ppid,pid,cmd | awk \$1 ~ /^Z/{print}\。遇到不确定的参数先tldr 命令名看简单示例必要时再翻 man。命令只是手排查思路才是脑把每个命令当成一次“提问”问得越准定位的速度就越快。 Linux常用命令实战：从权限到容器的排查思路
这一篇是Linux常用命令系列的第六篇。写下这个标题的时候我突然意识到这个系列已经被办公室同事当成了一本“应急小册子”在用。前几篇我们聊过文件、文本处理和基础网络这一篇我想换个角度不按命令字典的路子来而是按“问题现场”来讲你在排查用户权限、进程状态、日志异常、存储挂载和容器工具时究竟应该敲哪些命令为什么要敲这些命令踩过坑之后还能怎么补救。这个定位更适合两类人一是刚转运维或开发需要快速建立一套排查思路的同学二是被生产环境反复折腾过但缺少系统整理的老手。命令这东西背是背不完的真正值钱的是你脑子里那条“先看什么、再看什么、最后怎么办”的链路。1. 用户与会话别等权限出问题再回头补课1.1 新建用户的三个细节家目录、Shell和sudo新手最典型的一个坑就是用useradd建完用户切过去发现连家目录都没有。原因很简单CentOS/RHEL 系的useradd默认不会创建家目录除非你显式加了-m。正确的姿势大概是这样的sudo useradd -m -d /home/zhang -s /bin/bash zhang sudo passwd zhang sudo usermod -aG sudo zhang这里每个参数都不是摆设。-d指定家目录路径如果你不写默认会按/home/用户名来-s指定登录 Shell系统默认可能是 sh进去以后方向键、补齐和历史记录都别扭所以除非有特殊需求我统一用/bin/bash。-m的意思是同时创建家目录并且把/etc/skel里的模板文件复制进去像.bashrc、.profile这些初始配置都是这么来的。再强调一个容易忽略的细节useradd -D可以查看当前系统创建用户的默认值包括默认 Shell、家目录基准路径、默认用户组策略。批量上线账号前先执行一下这条命令能提前发现“为什么所有人建出来都是 nologin Shell”之类的幺蛾子。sudo 授权也有讲究。Debian/Ubuntu 系的发行版通常用sudo这个用户组而 CentOS 系用的是wheel。最常见的问题是明明把用户加进了组却依然无法 sudo很可能是改错了组名或者用了usermod -G而不是usermod -aG。-G会直接覆盖用户的附加组列表不加-a等于把用户之前加入的所有补充组全部清空轻则权限缺失重则连 docker 组、dev 组都没了。所以我的习惯是凡是追加组永远写全-aG。另外一个安全习惯是不要直接用vim /etc/sudoers去改文件除非你想被语法错误锁死。正确操作是visudo它会在保存前做语法检查。如果你要给某个用户特别权限建议在/etc/sudoers.d/下建一个独立文件比如echo zhang ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx | sudo tee /etc/sudoers.d/zhang-nginx sudo visudo -c生产环境尽量别用NOPASSWD: ALL那样和把一个 root 口令贴在工位上没什么区别。1.2 停用、锁定和删除删用户不是按个回车删除用户最干净的方式是userdel -r-r会连家目录和邮件池一起删。但在生产环境里我吃过一次亏有一个服务用 systemd 的Userdaemon跑着我直接删了那个用户结果一堆文件变成了数字 UID 所有排查了半天才反应过来。所以删除之前先查一下这个用户是否还有进程在跑ps -u olduser -o pid,cmd pkill -u olduser如果确认要删还建议先把家目录打个包再执行删除万一里面有配置文件和脚本后悔药还有得吃。另外运维审计要求不能删账户而必须锁账户时可以用sudo passwd -l olduser sudo usermod -L olduser两条命令都能让账户无法登录但侧重点略有不同。passwd -l是给密码字段加锁而usermod -L是直接锁定用户。真正常被忽略的是这两个操作都只影响后续登录已经建立的会话不会马上被踢掉。如果你需要立刻踢人还得配合pkill -u olduser或loginctl terminate-user olduser。顺带说一句lastlog和last前者能看每个用户最后登录时间后者看登录历史记录包括重启时间点。排查“谁半夜动过服务器”基本都是靠这两个命令起手。1.3 会话和后台运行别再用 nohup 硬扛了看当前系统上有谁在线我一般用w它能显示登录用户、终端、来源 IP、当前在跑什么命令比单纯的who信息全。需要看历史登录记录用last需要看失败登录记录要用lastb这个命令需要 root 权限。后台运行工具这块很多人一说就是nohup command 。说实话nohup 能解决“终端关闭后进程不退出”的问题但它解决不了“会话丢了就找不回来”的问题。如果任务是编译、数据同步、压测这种需要持续盯着的活我更推荐tmuxtmux new -s task # 跑你的命令然后 CtrlB 再按 D 脱离会话 tmux attach -t task为什么推荐它因为 tmux 把会话和服务端绑在一起就算你 SSH 断开、本机网络抖动会话里的进程也不会被 SIGHUP 带走下次连上去直接tmux attach就能接着看。nohup 能做的它都能做还能多窗口、分屏、日志回看。如果是临时起一个进程也可以考虑setsid command它会创建新的会话并脱离终端控制但操作体验和回看能力都不如 tmux。我的建议是一次性任务用 nohup需要长期跟踪的任务一律 tmux。1.4 口令策略和过期提醒密码过期这事其实挺容易踩坑。你以为设置了过期时间系统就会在用户登录时提醒但实际上很多环境里用户根本收不到提示因为他们用的密钥登录根本不会走到密码验证那一步。常见操作是把这三条配合起来sudo chage -M 90 zhang # 密码最长使用 90 天 sudo chage -W 7 zhang # 过期前 7 天开始警告 sudo chage -d 0 zhang # 强制下次登录改密码查看用户当前密码有效期用chage -l zhang清理临时账号也可以用chage -E 2025-12-31 zhang给它加一个失效日期。我自己写巡检脚本时会给所有用户循环执行chage -l再配合lastlog输出基本能覆盖大多数账户合规需求。2. 进程与资源用命令拼凑一张“现场图”2.1 别把 ps 当“拍一下照片”ps是最常用的进程查看命令但很多人只会ps -ef然后瞪眼找。我先说两个固定的看点ps -ef输出里PPID是指父进程 IDC是 CPU 使用率ps aux输出里%CPU、%MEM、VSZ、RSS这些字段非常直白RSS 是物理内存占用VSZ 是虚拟内存。排查内存泄漏时我会先用ps aux --sort-%mem | head把内存占用 Top10 拎出来。再一个是过滤技巧。直接ps -ef | grep nginx经常会带出那条 grep 自身的进程很碍眼。更稳的办法是用pgreppgrep -f nginx: worker-f表示匹配完整命令行而不仅仅是进程名。这在过滤脚本类进程时尤其有用比如pgrep -f python.*app.py。但注意-f匹配的是整个命令行如果命令行里包含特殊字符且不带引号容易把自己 bash 的历史命令也匹配出来所以使用前最好先用ps -eo pid,cmd | grep ...验证一下。2.2 top 的批处理模式和 load average 怎么读交互式top我基本只在临时看两眼的时候用真正写进脚本和排查记录里的是批处理模式top -bn1 -o %MEM | head -20-b是批处理不刷屏-n1只采样一次-o %MEM按内存排序等价于交互界面按大写 M。按 CPU 排序用-o %CPU只看某个进程用top -p PID只看指定用户用top -u zhang。很多人对 load average 的理解是有偏差的。load average: 5.8, 3.2, 2.0分别表示 1 分钟、5 分钟、15 分钟的平均活跃进程数。但如果机器是 8 核5.8 并不算高反而说明有约 2 个核的空闲如果是 4 核5.8 就已经超载了。更重要的是load 高不一定代表 CPU 忙还有可能是大量进程进入了不可中断的D状态比如 NFS 挂载失联、磁盘 IO 卡死。这时候 CPU 使用率可能很低但系统已经处于半瘫痪状态。所以看到 load 高先top看一眼排前面的进程状态是 R 还是 D再往下查。2.3 进程启动时间和“进程名对不上号”的问题排查“这个服务到底什么时候被重启过”最直接的是这条ps -p PID -o pid,lstart,etime,user,cmdlstart是进程启动的绝对时间etime是已经运行了多久。配合最近的上线记录或定时任务日志基本就能对上号。但这里有个高级一点的坑Linux 进程名是可以被修改的。服务本身可以通过prctl(PR_SET_NAME)改自己的 comm 字段启动脚本也可以用exec -a custom_name ./your_binary把 ps 显示的名字改成别的。所以常在 ps 里看到一个进程叫myserver但它实际跑的是一个叫backup_agent.so的动态库程序。识别真实程序的办法很简单readlink -f /proc/PID/exe这条命令能告诉你这个进程真正执行的二进制文件路径比看 ps 输出靠谱得多。排查可疑进程时/proc/PID/exe、/proc/PID/cwd、/proc/PID/environ这三个文件是必看的。2.4 僵尸进程kill -9 治不了的病僵尸进程的标志是在ps输出里状态那列显示Z命令行最后带着defunct。它的本质是子进程已经退出但父进程没有调用 wait 回收它的退出状态。所以kill -9对僵尸进程完全无效——它不是活着的进程你杀不掉一个已经死了的进程。定位僵尸进程可以这样ps -A -o stat,ppid,pid,cmd | awk $1 ~ /^Z/拿到 PPID 后往上看这个父进程是什么父进程如果没有异常就让它自己回收如果父进程卡住了通常要重启或干掉父进程让僵尸变成孤儿被 init 收养再由 init 统一回收。生产环境里我见过大量僵尸集中在某个宿主机底层原因多半是容器里的 PID 1 进程没有正确处理子进程退出信号或者 Java 程序的父进程没有 wait。这种问题在容器监控里非常典型需要应用层面配合处理而不是在操作系统层面硬杀。2.5 资源限制连接数上不去先查 ulimit高并发场景下最常见的报错是 Too many open files。这跟文件描述符fd上限有关默认值在多数系统上是 1024对 web 服务来说远远不够。查看当前限制和给指定进程设置限制的方法ulimit -n ulimit -n 65535永久修改通常写在/etc/security/limits.conf或/etc/security/limits.d/下* soft nofile 65535 * hard nofile 65535不过要注意区分 soft 和 hardsoft 是当前会话可以自行提升到的上限hard 是硬性天花板。修改后必须重新登录或重启服务才生效这也解释了为什么很多同事改了 limits.conf 以后跑起来的进程仍然报 1024。验证进程实际生效值可以查cat /proc/PID/limits排查 fd 占用数量用lsof -p PID | wc -l如果这个数字持续上涨且不回落基本可以断定是哪里连接没有释放顺着 lsof 的输出继续查 FD 类型就行。3. 日志检索把 tail、grep、awk 串成一条流水线3.1 grep 的正确姿势上下文、边界和二进制从日志里捞有效信息第一反应是 grep但很多人只会grep error app.log。我要补几个常用姿势grep -E ERROR|timeout|deadlock app.log | head -50 grep ProductAPI access.log -A 2 -B 2 grep -w 404 access.log-A 2 -B 2是显示匹配行的前后 2 行这个在查堆栈和异常上下文时简直是救命稻草。-w是单词边界匹配避免你把404和4040混在一起。-E是多条件或正则匹配比写好几个管道再合并干净得多。还有一个非常烦人的问题是二进制文件。日志文件里混进了少量 \0 字节grep 就会输出Binary file app.log matches结果什么都看不到。解决办法是加-a或--text强制按文本处理。递归搜索日志目录时我建议直接用grep -rn --include*.log ERROR /var/log/app/3.2 按时间段抽取sed 和 awk 的分工日志定位最常遇到的问题就是“这五分钟之内到底发生了什么”。如果日志格式整齐每行开头是2025-02-01 12:30:00可以用 sed 按行范围切sed -n /^2025-02-01 12:30:00/,/^2025-02-01 12:35:00/p app.log但 sed 有个前提就是日志本身是按时间顺序排的。如果日志文件被多线程写、被切割合并过顺序乱了sed 这套就不靠谱了。更通用的做法是用 awk 对字段进行比较awk /^2025-02-01/ $2 12:30:00 $2 12:35:00 app.log这里假设$1是日期、$2是时间字段分隔符是空格。如果日期格式不是标准开头可以先用 grep 粗筛再用 awk 精切。我处理 10GB 大日志时经常是先grep 2025-02-01 big.log day.log把文件拉到 GB 级别以内后面 sed 和 awk 的速度才会理想。3.3 统计与去重sort uniq 才是完整搭档想分析访问日志里哪些 IP 最活跃最简单的流水线是cut -d -f1 access.log | sort | uniq -c | sort -rn | head -10这段命令的意思是用 cut 切出 IP 列sort 排序让相同 IP 挨在一起uniq -c 统计次数再按次数倒序取前 10。很多人只用uniq就发现统计不对那是因为 uniq 只会合并相邻的重复行不先 sort 的话相同 IP 分散在文件各处根本合并不到一起。统计 HTTP 状态码分布同理awk {print $9} access.log | sort | uniq -c | sort -rn如果是四段式 nginx 日志状态码字段在第 9 列如果是其他格式可以先head -1 access.log确认字段位置。这套组合我每天都在用跑完一眼就能看出 5xx 是否激增。3.4 实时追踪tail -F 和 tail -f 不是一回事看日志实时输出用tail -f没错但生产环境里日志经常按天轮转比如 nginx 的 access.log 会被 rename 成 access.log.20250201再新建一个 access.log。这时候你原来的tail -f还在盯着旧文件的 fd新日志进来你完全看不见。正确做法是tail -F /var/log/app/app.log大写 F 会按文件名追踪文件被轮转后会重新打开新文件。这个坑我踩过不止一次排查了半小时才发现日志一直没滚动问题不在程序而在 tail 的参数。配合管道过滤可以这样tail -F app.log | grep --line-buffered ERROR如果用的是 systemd 管理的服务直接看 journal 更省事journalctl -u my-service -f --since 1 hour ago journalctl -u my-service --since 2025-02-01 12:30:00 --until 2025-02-01 12:35:003.5 大日志文件别用 catless 才是阅读利器我总是跟新人说看到一个 5GB 的日志千万别cat。正确工具是lessless app.log打开后按/ERROR搜索n跳下一处N跳上一处按G跳到文件尾按g跳到文件头按F进入类似于 tail -f 的跟随模式CtrlC 中断跟随直接读压缩日志less app.log.gz甚至zcat app.log.gz | head -50。从这里你会发现一段好的排查思路其实就是 tail、grep、awk、sed、less 这几个命令的组合单拎出来都简单但组合起来能解决绝大多数日志问题。4. 网络与存储从连通性到挂载的排查套路4.1 端口与服务用 ss 替代 netstat排查“端口明明在监听为什么从外面连不上”我有一套固定顺序。先看端口是否在本地监听ss -tulnp | grep 8080-t看 TCP-u看 UDP-l只看监听-n不做域名反解-p显示进程信息避免用 netstat 还要等半天反向解析。接着看有没有进程占着端口lsof -i :8080如果监听正常再去验证对方能不能通nc -vz 192.168.1.10 8080-v显示详细过程-z表示只扫描端口不发送数据。如果 IP 能 ping 通但端口不通基本就是防火墙拦截检查顺序是firewall-cmd --list-all或iptables -L -n -v。这里我要提醒一点很多云主机的安全组规则是云平台层面控制的操作系统里 iptables 是空的那问题十有八九出在安全组别再反复重启服务了。处理建连数异常可以用 ss 统计ss -ant state established ( dport :443 ) | wc -l看 TIME_WAIT 状态的连接数量能帮你判断端口耗尽类问题。4.2 DNS 排查别忽略 systemd-resolved解析出问题时的排查路径一般是先手动解析目标域名再检查系统接入的 DNS 配置。手动解析用 digdig short www.example.comshort只输出 IP非常干净。nslookup 也可以但输出冗余我日常用 dig 更多。然后看/etc/resolv.conf确认 nameserver 指向哪里。如果你用的 Ubuntu 18.04 以上版本这个文件很可能是被 systemd-resolved 管理的手动改了以后重启网络又会被覆盖。查看实际生效的 DNS 状态resolvectl status清 DNS 缓存用resolvectl flush-caches很多“域名突然解析失败”的假故障其实是缓存了过期的 A 记录清一次缓存就好了。4.3 NFS 和 CIFS 挂载挂在墙上的不是命令是坑挂载 NAS 存储NFS 最常见的挂载格式sudo mount -t nfs4 -o rw,bg,hard,intr,noatime 192.168.10.5:/data /mnt/databg表示后台重试挂载失败时不会一直卡住终端hard是硬挂载intr允许中断这两个配合起来能让进程在 NFS 失联时可被 CtrlC 打断。如果你用的是软挂载softNFS 服务抖动时会直接给应用返回 IO 错误数据库之类的在线服务很容易写坏文件所以生产场景我一般倾向 hard。但是 hard 挂载最大的副作用是NFS 服务彻底失联时ls那个目录会一直卡住整个进程进入 D 状态连 kill -9 都没反应。所以重要目录的 fstab 条目一定要考虑是否加nofail。Windows/CIFS 共享挂载是另一套参数sudo mount -t cifs //192.168.10.20/share /mnt/share -o usernamebackup,passwordxxx,vers3.0,secntlmssp这里指定vers3.0是防止老版本协议协商失败或安全性过差。挂在/etc/fstab时有一个容易被忽略的选项是_netdev它告诉系统“这是网络设备等网络就绪后再挂载”不加它开机容易因为网卡没起来而挂载失败严重时会卡在启动流程。一个参考条目192.168.10.5:/data /mnt/data nfs4 defaults,_netdev,nofail,noatime,hard,intr 0 0写完之后先sudo mount -a验证语法再用findmnt --verify检查 fstab 内容。NFS 挂载信息查看nfsstat -m卸载不掉的挂载点用sudo umount -l /mnt/data-l是 lazy 卸载先把挂载点从目录树中摘除等 IO 结束后再真正收尾。这种操作适合 NFS server 已经失联的紧急情况。4.4 磁盘和 inodedf、du 之外还要会看 lsof磁盘排查最基础的是df -h和du -sh。但如果你发现df -h显示分区已满du -sh在对应目录统计出来的总量却对不上优先怀疑一件事有文件被进程删除但还没释放。Linux 下删掉的 open file 不会立刻释放空间只有进程关闭 fd 才能释放。查找这种“隐形大文件”lsof L1L1表示列出 link count 为 0 的被删文件看到 PID 和进程名后重启对应进程即可释放空间。inode 耗尽也是一种满表现是df -h还有空间但无法创建文件。用df -i查看 inode 使用率。如果确实被大量小文件塞满可以用find /data -xdev -type f -size 1G -exec ls -lh {} \; 2/dev/null-xdev限定不跨文件系统避免扫到挂载点深处把结果搞混。找大文件和清 inode 是两个完全不同的思路别混在一起。5. 绕不开的工具命令Docker、Redis、HDFS、GDB、ADB5.1 Docker日志、进容器、看资源占用容器环境下的常用命令已经变成了日常的一部分。我写几个最常用的docker ps -a docker logs -f --tail200 my-container docker exec -it my-container bash docker stats --no-stream docker inspect -f {{.NetworkSettings.IPAddress}} my-container docker top my-containerdocker logs --tail200避免直接把几千行日志打到终端docker inspect后面那串 Go 模板语法看着唬人实际上就是在取容器 IPdocker top能看到容器内进程在宿主机上的真实 PID排查资源问题时常需要它。不要用docker attach它和容器的主进程共享 stdin/stdout用的时候一按 CtrlC 很容易把容器也停掉。理由很简单attach是直接连主进程exec是开一个新的交互进程后者安全得多。5.2 Redis宁可慢也不要用 KEYS排查 Redis 问题先redis-cli ping确认还活着然后这几个命令轮流上redis-cli INFO memory redis-cli INFO stats redis-cli --scan --pattern cache:* | head -20 redis-cli SLOWLOG GET 10 redis-cli DBSIZE redis-cli TYPE user:10086INFO系列是诊断一切的入口内存、客户端连接数、命中率都在这。需要匹配大量 key 时用--scan --pattern千万不要用KEYS *因为 KEYS 会阻塞整个 Redis 实例在生产环境上等于自杀。慢查询日志SLOWLOG GET能看到耗时过久的命令再配合客户端 IP 去定位调用方是排查 Redis 性能问题最常见的一条线。5.3 HDFS大数据同学的大文件操作HDFS 和本地文件系统的命令风格很像但细节不同hdfs dfs -ls -R /data hdfs dfs -mkdir -p /user/zhang hdfs dfs -put local_file /user/zhang/ hdfs dfs -get /user/zhang/remote_file ./local_file hdfs dfs -du -h /user/zhang hdfs dfs -rm -r /user/zhang/tmp_dir hdfs dfs -tail /user/zhang/log.txt-du -h可以快速看目录下每个子目录的空间占用排查“哪个目录把磁盘吃完了”很好用。HDFS 对小文件非常不友好NameNode 会把每个文件、目录和 block 的元数据都放在内存里上百万个小文件直接能把内存吃光。所以新人在做数据采集时我建议先考虑合并写入而不是堆零散文件。如果已经积累了一批小文件可以用hdfs dfs -getmerge到本地再传回去或者在调度层用 coalesce 处理。5.4 GDB调试崩溃程序的最后手段GDB 看起来是 C/C 开发者的工具但运维在排查 core dump 时也离不开。最基本的流程gdb ./your_program core.12345 (gdb) bt (gdb) info registers (gdb) info threads (gdb) thread 2bt打印调用栈崩溃现场第一件事就是btinfo registers看寄存器值配合反汇编分析更细的问题。如果程序还在跑可以这样挂上去sudo gdb -p PID在 GDB 里执行continue让进程继续跑等到问题复现。需要注意两点一是对生产环境重要进程执行 gdb -p 会暂停进程虽然可以 continue但极短的停顿对在线服务也可能造成抖动尽量在低峰期操作二是让 core dump 能生成的话要先设置ulimit -c unlimited不要忘记检查 core 文件生成路径通过sysctl kernel.core_pattern查看。否则段错误程序跑崩了你四处找 core路径却指向 systemd-coredump 管理的目录白忙一场。5.5 ADB嵌入式开发调试的瑞士军刀在嵌入式、Android 或电视盒子类设备上调试ADB 是绕不开的。最常用的几组命令adb devices adb -s 设备序列号 shell adb shell logcat -s MyApp:I adb push ./app.apk /data/local/tmp/ adb reverse tcp:8080 tcp:8080 adb install -r app.apk adb kill-server多设备同时插在电脑上时直接adb shell会报错提示有多台设备必须加-s选设备序列号。adb reverse的作用是把设备上的端口映射到本机调试 Web 页面时很实用。设备连不上时先怀疑 adb server 状态执行adb kill-server再重新adb devices一般能解决。这几个命令虽然不属于服务器运维核心但做 Linux 系统的嵌入式方向完全离不开。6. 现场问题速查记录我踩过的那些坑6.1 tail -f 看不到新日志现象日志文件确实在更新但tail -f不输出。原因日志轮转工具把 access.log 改名tail 还抱着旧文件的 fd。解决改用tail -F。这是我列为“新人必踩第一名”的坑没有任何例外情况。6.2 grep 命中但显示 Binary file matches原因文件中有 \0 字节grep 判定为二进制。解决加-a强制文本模式或者用--include*.log先过滤再搜。不要因为这个问题就加-r盲目扫描范围越大越容易被二进制文件干扰。6.3 ps 看到的进程名完全对不上二进制原因进程用prctl或启动脚本用exec -a改了 argv[0]。解决用readlink -f /proc/PID/exe看真实路径。排查恶意进程或“看不懂的异常进程”时这条是杀手锏。6.4 /etc/fstab 写错导致开机进 emergency mode现象重启后系统停在 emergency mode。原因fstab 里某条挂载配置错误文件系统挂载失败。解决输入 root 密码进入维护模式注释掉或修正错误行然后mount -a验证。预防修改 fstab 之前先备份改完用findmnt --verify检查语法。6.5 NFS 失联所有进程呈 D 状态kill 不掉现象load average 飙升ps 里大量 D 状态进程。原因NFS server 宕机或网络中断硬挂载的进程阻塞在 IO 上。解决先恢复网络或 NFS 服务再用umount -l摘除挂载点实在不行重启对端服务。在线事务型应用不要把核心数据目录直接放 NFS集群文件系统另选方案。6.6 新建用户无法 sudo现象用户明明在 sudo 组却提示 not in the sudoers file。原因要么组名不对Ubuntu 是 sudoCentOS 是 wheel要么usermod -G覆盖了原由的附加组。解决确认发行版默认 sudo 组使用usermod -aG 组名 用户并visudo -c校验。下面这张速查表是我贴在工位上的一份常用对照适合打印出来现象典型命令补充说明端口被占用ss -tulnp优先用 ss不用 netstat哪个目录占空间du -h --max-depth1配合 sort -h 看从大到小文件删了空间没释放lsof L1找被删除但仍打开的文件日志只追新不追旧tail -F处理轮转日志必须用大写 F进程真实路径readlink -f /proc/PID/exe比 ps 输出更可靠容器内看宿主机进程docker top不要只在容器里看 ps分析访问日志 Top IPcut -d -f1 log | sort | uniq -c | sort -rn必须先 sort 再 uniq我个人在这些命令上花的冤枉时间不算少所以最后再分享一个小习惯不要试图把命令背全而是围绕“问题类型”去建自己的速查脚本。比如我会在~/.bashrc里放几个 aliasalias portsss -tulnp、alias du1du -h --max-depth1 | sort -h、alias zzps -A -o stat,ppid,pid,cmd | awk \$1 ~ /^Z/{print}\。遇到不确定的参数先tldr 命令名看简单示例必要时再翻 man。命令只是手排查思路才是脑把每个命令当成一次“提问”问得越准定位的速度就越快。