前言

crontab 写好了却到点不执行，是服务器运维最常见的坑之一。手动跑脚本正常，定时任务却没反应，问题往往不在脚本本身，而在服务状态、环境变量、时间格式和权限。本篇按从易到难的顺序列出排查点。

一、先确认crond服务在运行

systemctl status crond
# 没启动就启动并设开机自启
systemctl start crond
systemctl enable crond

服务没跑，所有定时任务都不会触发，这是第一个要查的。

二、检查定时任务格式是否正确

标准格式：分 时 日 月 周 命令

# 查看当前用户的定时任务
crontab -l
# 例如：每10分钟执行一次脚本
*/10 * * * * /usr/bin/php /www/backup.php

常见格式错误：分钟位置写成了小时、用了 * 却想表示"第1个"、命令路径用了相对路径。

三、查看cron日志，判断有没有触发

# CentOS7 日志位置
tail -f /var/log/cron

到点看日志里有没有出现这条任务：

• 日志里根本没有：格式没被识别、服务没跑、或时间写错；
• 日志有执行记录但没效果：是脚本/环境问题，往下查。

四、脚本环境变量问题（高频）

cron 的环境比手动登录干净得多，很多命令找不到、相对路径失败。解决：

1. 用绝对路径：脚本里和任务里都写全，比如 /usr/bin/php、/www/backup.php；
2. 开头加载环境：

   */10 * * * * source /etc/profile; /usr/bin/php /www/backup.php

3. 先手动用cron环境复现：env -i /bin/bash script.sh 模拟干净环境跑一遍。

五、权限与重定向

• 脚本要有执行权限：chmod +x /www/backup.sh；
• 脚本没加 shebang（#!/bin/bash）会找不到解释器；
• 把错误输出留下来方便定位：

  */10 * * * * /usr/bin/php /www/backup.php >> /www/log/cron.log 2>&1

  加了 2>&1，报错就写进日志，不再"静默失败"。

六、其他易漏点

1. 时区不一致：timedatectl 看系统时区，容器里时间错会导致任务错位；
2. 日和周同时指定是"或"关系，容易误触发，注意语义；
3. root和普通用户任务混淆：sudo crontab -l 看root的，普通用户看自己的；
4. 磁盘满了：日志写不进去，任务看似没执行。

总结

排查顺序：crond服务是否运行 → 任务格式对不对 → /var/log/cron 有没有触发 → 绝对路径和环境变量 → 执行权限与错误重定向 → 时区。手动正常、定时不跑，九成是环境变量和绝对路径问题。

遇到问题加QQ23979811 协助处理

Linux查看目录占用

引言

磁盘满了先定位是哪个目录吃掉空间，df看整体分区，du逐层下钻找大户。两个命令配合，从分区到目录到文件逐级缩小范围，是磁盘排查的标准路径。

看整体分区：df

df -h

人类可读格式显示各分区总量、已用、可用、使用率，先判断是哪个挂载点满了。

看单个目录总大小

du -sh /var/log

-s汇总，-h人类可读，直接给出这个目录总共占多大。

看一级子目录大小并排序

du -h --max-depth=1 /var | sort -rh | head

只算一层子目录，sort -rh按人类可读大小倒序，head取前几名，快速定位大户。

常用简写

du -sh /var/*

列出/var下每个一级目录大小，逐层进入继续排查。

排除文件系统统计

du -shx /home

-x不跨文件系统，避免把挂载的别的盘也算进来。

看目录下文件数量

ls /var/log | wc -l

有些目录不大但文件海量，inode耗尽也会写不进，配合df -i看inode。

注意事项

• df看分区，du看目录，先df定位再du下钻；
• 大目录du会遍历较慢，加--max-depth限制层数；
• 删除大文件后空间没释放，可能是进程仍持有句柄，需重启进程；
• sort -rh依赖du输出的G/M单位；
• /proc、/sys是虚拟文件系统，du统计无意义；
• 日志目录优先排查，常是增长最快的大户。

总结

df -h看分区整体，du -sh看单目录汇总，--max-depth=1配合sort -rh找一级大户，-x不跨文件系统，ls加wc -l看文件数，df -i查inode。排查路径是先df定位满的分区，再du逐层下钻，删文件后空间不释放要查持有句柄的进程，日志目录优先检查。

Linux查看系统版本

引言

接手一台服务器，第一件事是搞清楚发行版是CentOS、Ubuntu还是Debian、内核多少位、版本号多少，因为包管理器、软件源、命令差异都跟发行版绑定。下面几组命令覆盖发行版、内核、架构三个维度。

看发行版版本（推荐）

cat /etc/os-release

现代发行版通用，输出NAME、VERSION、PRETTY_NAME，CentOS、Ubuntu、Debian都适用。

看CentOS具体版本

cat /etc/redhat-release
# 或
rpm -q centos-release

RHEL系专用，直接显示CentOS Linux 7/8等版本号。

看Ubuntu/Debian版本

lsb_release -a
# 或
cat /etc/debian_version

lsb_release显示Distributor和Release，没装时读debian_version兜底。

看内核版本

uname -r
# 完整信息
uname -a

-r看内核版本号，-a连架构、主机名、编译时间一起输出。

看CPU架构

arch
# 或
uname -m

x86_64是64位，aarch64是ARM，选安装包时必须对应。

看系统位数和硬件

getconf LONG_BIT

输出32或64，比uname更直接回答多少位。

注意事项

• 发行版和内核是两回事，Ubuntu 22.04可以换内核；
• 包管理器按发行版选：CentOS用yum/dnf，Ubuntu用apt；
• 容器内cat /etc/os-release看到的是镜像版本，不是宿主机；
• 老系统可能没有os-release，用redhat-release或issue兜底；
• 生产升级内核前先uname -r记录当前版本便于回退；
• 脚本里判断发行版读/etc/os-release的ID字段最稳。

总结

cat /etc/os-release看通用发行版，redhat-release看CentOS，lsb_release看Ubuntu，uname -r看内核，arch/uname -m看架构，getconf LONG_BIT看位数。先分清发行版和内核，包管理器按发行版选，容器内读到的是镜像版本，脚本判断优先解析os-release的ID字段，升级内核前记录当前版本方便回退。

Nginx配置检查测试

引言

改完Nginx配置直接reload最容易踩坑：语法错、证书路径错、端口被占会导致Nginx起不来甚至站点全挂。规范流程是先检查语法，通过后再平滑重载，出问题能快速回退。

语法检查

nginx -t

检查默认配置文件语法，输出syntax ok和test is successful才说明配置无误。

指定配置文件检查

nginx -t -c /etc/nginx/nginx.conf

自定义路径时用-c指定，避免检查错文件。

平滑重载

nginx -s reload

不中断现有连接重新加载配置，改动生效不宕机。

查看编译参数和版本

nginx -V

大写V看版本和编译模块，确认是否包含ssl、gzip、stream等模块。

打印生效配置

nginx -T

大写T会把所有include进来的配置打印出来，排查重复server或覆盖时用。

出错常见原因

• 括号不配对、分号漏写；
• 证书key路径不存在或权限600不对；
• listen端口已被其他进程占用；
• upstream后端地址写错；
• include路径下的文件本身语法错。

注意事项

• 永远先-t再reload，禁止跳过检查；
• 改配置前备份原文件，出错可立刻回退；
• -T输出很长，重定向到文件再查；
• reload失败先看error.log定位行号；
• 生产环境改完curl本机验证再放行；
• 多台机器逐台灰度，不要一次全改。

总结

nginx -t检查语法，-c指定文件，-s reload平滑生效，-V看编译模块，-T打印完整配置。铁律是先检查通过再重载，改前备份、出错看error.log、本机curl验证后再上线，生产逐台灰度，避免一次改全量导致整站不可用。

Linux查看CPU信息

引言

服务器扩容、压测、排查性能瓶颈前，先要知道机器几颗CPU、多少核、主频和架构。/proc/cpuinfo是内核暴露的原生信息，配合lscpu、nproc能快速拿到规格，top/mpstat再看实时占用。

lscpu看汇总

lscpu

一次列出架构、颗数、每颗核数、线程数、主频、缓存，最简洁。

nproc看逻辑核数

nproc

直接输出可用逻辑CPU数，脚本里取核数最方便。

读/proc/cpuinfo

cat /proc/cpuinfo

每颗逻辑核一段，看model name型号、cpu MHz频率、flags指令集。

统计物理颗数和核数

# 物理CPU颗数
grep "physical id" /proc/cpuinfo | sort -u | wc -l
# 每颗物理核数
grep "cpu cores" /proc/cpuinfo | uniq
# 逻辑核总数
grep -c processor /proc/cpuinfo

物理颗数×每颗核数×超线程=逻辑核数。

实时CPU占用

top
mpstat 1

top看整体和进程，mpstat每秒采样看用户态、系统态、idle占比。

注意事项

• 云主机看到的是分配的vCPU，不一定是物理独占；
• 超线程逻辑核不等于物理性能翻倍；
• flags里看是否支持虚拟化、AVX等指令集；
• 排查高占用先top按P按CPU排序找进程；
• 结合uptime看负载和核数是否匹配；
• lscpu在大部分发行版预装，无此命令再读/proc。

总结

规格用lscpu看汇总、nproc取核数、/proc/cpuinfo读型号和指令集，配合grep统计物理颗数与核数，实时占用用top和mpstat。压测和扩容前先分清物理核、逻辑核和超线程，避免按vCPU误判真实算力。

Linux查找大文件

引言

服务器磁盘爆满时，df先看哪个分区满，再用du一层层往下钻，找到吃掉空间的大目录和大文件。很多人只会df -h，却定位不到具体是哪个文件，这里讲完整排查链路。

第一步看分区占用

df -h

看Use%和挂载点，确认是/、/data还是/var满，别在没满的分区里瞎找。

第二步定位大目录

du -sh /* 2>/dev/null | sort -rh | head

du -sh统计每个一级目录大小，sort -rh按大小倒序，head取前几名，快速锁定大头目录，再逐层深入：

du -sh /var/* 2>/dev/null | sort -rh | head

第三步找超过100M的单文件

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

-size +100M表示大于100MB，2>/dev/null丢弃无权限报错，直接列出大文件路径和大小。

常见膨胀位置

• /var/log：日志没轮转，单个日志几个G；
• /tmp：临时文件没清理；
• Docker：/var/lib/docker镜像和容器层堆积；
• 网站上传目录、数据库binlog。

处理建议

• 日志优先清空而不是删文件（> log.log），避免占用文件句柄不释放；
• Docker用docker system prune清理悬空镜像；
• 删之前确认文件没被进程占用，lsof | grep 文件名；
• 不要直接rm正在写入的日志，用truncate -s 0截断。

注意事项

• du统计含磁盘占用，find看文件真实大小，两者结合；
• 根目录全盘find慢，先缩小到df定位的分区；
• 系统目录(/usr、/lib)别乱删，只清理业务数据和日志。

总结

df -h定位满的分区，du -sh逐层排序找大目录，find -size找大文件，先看日志和Docker，清空用truncate别rm占用文件。按分区→目录→文件三层下钻，几分钟就能找到磁盘元凶。