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 <code>PID看进程在等什么系统调用（如futex表示锁竞争，recvfrom可能是网络阻塞） - 补充：
kill -0 <code>PID可无害检测进程是否存在，常用于脚本健康检查
事情说清了就结束。运维里最耗时间的，往往不是学新命令，而是意识到「默认行为」和「你以为的行为」之间那层薄薄的偏差。
