Linux 运维新人常见误区总结

sudo执行脚本失败主因是环境变量重置而非权限问题，PATH等变量被替换为root默认值，需用sudo env “PATH=$PATH”临时修复或显式设置PATH。

用 sudo 直接执行脚本却没生效？权限和环境变量不一致才是真因

很多新人写完脚本，sudo ./deploy.sh 一跑，报错说找不到 python3 或 jq，但明明自己 which python3 能看到。问题不在权限，而在 sudo 默认重置了大部分环境变量，尤其是 $PATH。

• sudo 会使用目标用户的 PATH（通常是 root 的），而 root 的 PATH 往往不含 /usr/local/bin 或用户自定义路径
• 临时解决：用 sudo env "PATH=$PATH" ./deploy.sh；长期方案是把依赖工具装到 root 可见路径，或在脚本开头显式设置 PATH
• 更隐蔽的坑：某些命令（如 systemctl --user）依赖 $XDG_RUNTIME_DIR，sudo 下这个变量为空，直接失败

df -h 显示磁盘满，但 du -sh * 加起来远小于总量？别急着删日志

这是最典型的“空间消失”现象——根本不是文件占满，而是被已删除但仍在运行进程持有的文件句柄占着。常见于长时间运行的 Web 服务、数据库或日志轮转不彻底的场景。

• 先确认：运行 lsof +L1，看输出里有没有标记为 (deleted) 的大文件
• 定位进程：lsof +L1 | grep deleted | head -n 5，重点关注 PID 和文件大小
• 处理方式：重启对应进程（如 systemctl restart nginx），或用 kill -USR1 触发日志 reopen（Nginx 支持，apache 不一定）
• 注意：rm -f 对这类文件无效，必须释放句柄

写定时任务只加 crontab -e 就完事？忽略 SHELL 和 PATH 是最大盲区

crontab 默认用 /bin/sh 执行，且 PATH 极其有限（通常只有 /usr/bin:/bin）。你本地能跑通的 node、pip3、甚至 lsb_release，在 cron 里大概率报 command not found。

• 务必在 crontab 文件顶部显式声明：SHELL=/bin/bash 和 PATH=/usr/local/bin:/usr/bin:/bin
• 更稳妥的做法：所有命令写绝对路径，比如用 /usr/bin/python3 而非 python3
• 调试技巧：把命令重定向输出到文件，* * * * * /path/to/script.sh >> /tmp/cron.log 2>&1，否则失败静默无痕
• 注意：系统级 /etc/crontab 格式不同，多一列用户名，别混用

用 kill -9 解决一切进程卡死？可能让数据损坏或锁残留

kill -9（即 SIGKILL）跳过所有清理逻辑，对数据库、消息队列、文件锁管理类进程极其危险。它不会触发进程的 shutdown hook，也不会释放内核级资源。

• 正确顺序：先 kill（默认 SIGTERM），等 10–30 秒；没退出再考虑 kill -9
• 关键服务（如 postgres、redis-server）必须用服务管理命令：systemctl stop postgresql，它内部做了优雅停止
• 验证是否真卡死：strace -p PID 看进程在等什么系统调用（如 futex 表示锁竞争，recvfrom 可能是网络阻塞）
• 补充：kill -0 PID 可无害检测进程是否存在，常用于脚本健康检查

事情说清了就结束。运维里最耗时间的，往往不是学新命令，而是意识到「默认行为」和「你以为的行为」之间那层薄薄的偏差。