Linux计划任务与进程管理：cron到systemd timer排障指南

做 Linux 运维和开发的朋友恐怕没有谁不认识 cron。服务器上定时备份、日志切割、数据同步、健康巡检绝大多数都是靠计划任务在背后默默顶着。但计划任务这东西有个很有意思的现象平时配置好就不怎么管了一旦出问题你会发现所有线索都绕不开一个词——进程。任务为什么没跑为什么跑重了为什么 kill 掉的 PID 过一会儿又出现了为什么脚本明明手动执行没问题放 cron 里就报 command not found这些坑背后其实是计划任务体系和 Linux 进程模型之间的那层关系没理清。这篇文章我想把“Linux 计划任务”和“进程”放到一起来聊从 cron 的执行机制、环境差异到 crontab 和 systemd timer 的正确姿势再到任务跑起来之后怎么借ps、日志、进程树做现场排查最后聊一聊大家都遇到过的那种“杀不死的进程”到底是怎么回事。内容面向运维、后端开发和刚接触 Linux 的读者不堆理论全部是能直接照抄的操作和排查思路。在 Linux 服务器上工作久了你会发现计划任务这东西平时脾气挺好一旦出了问题坑跟连环套一样。这篇就专门聊聊“计划任务”和“进程”之间的那些事cron 本身是进程它拉起来的任务是进程任务里再起的后台服务还是进程。每一个环节的异常最终都会以“进程”的形态暴露出来。搞懂这条链排障就能快一半。1. 先搞懂计划任务到底是由哪些进程撑起来的1.1 一条计划任务的完整进程链很多刚接触 Linux 的人会以为cron 就是系统在某个时刻替你执行一条命令命令跑完就结束了。但实际上计划任务的执行是一整条进程链的协作链条的起点是那个常驻内存的守护进程crond。crond是 Linux 下最常见的计划任务守护进程部分发行版里它的名字直接叫cron。它启动后常驻后台每隔一分钟检查一次调度表看看当前时间有没有到点的任务。到了点的任务并不会由crond自己直接去执行而是走一套标准的 Unix 进程创建流程先fork()出一个子进程再由这个子进程exec()去加载/bin/sh最后由这个 shell 去解释执行你在 crontab 里写的那条命令。所以一条最简单的计划任务真正跑起来时进程树长这样crond父进程 └── sh -c 你的命令子进程 └── 具体脚本/程序如果在命令里执行的是脚本它会是 sh 的子进程为什么要绕这一圈而不让crond直接跑核心原因是隔离。crond自己是个要长期稳定运行的守护进程如果把用户的任务直接在它内部执行脚本一旦死循环、卡在网络等待上、或者触发内存暴涨整个调度系统就会被拖垮。fork()出子进程之后即使子进程崩了crond本体毫发无伤下一分钟照样调度新任务。这个设计思路和 nginx 的 master-worker 模型、以及 Redis 的 fork 持久化是同一个祖宗都是“核心进程保持纯粹具体工作交给子进程”。要验证这一点也很简单在服务器上执行ps -ef --forest | grep -A 5 crond就能看到crond下面挂着的子 shell。如果你没有正在执行的任务就看不到子孙进程这是正常的因为任务执行完就退出了。1.2 为什么计划任务里的进程容易“找不着爹”这是计划任务和进程关系中最容易踩的暗坑由crond拉起的任务进程是脱离终端的。你在 SSH 终端里手动执行脚本关掉终端时 shell 会给前台进程发送 SIGHUP 信号把进程带走。但计划任务不是在你终端里跑的它没有控制终端所以你退出 SSH 对正在执行的计划任务毫无影响。这在很多场景下是好事但也带来了一个副作用如果脚本内部再启动后台进程这个后台进程和脚本所在 shell 的关系会变得微妙。最常见的翻车现场是这样的#!/bin/bash /opt/myapp/start.sh 脚本执行到这里start.sh在后台运行脚本主体继续往下走。当脚本执行完毕退出后这个后台子进程的父进程就变成了 PID 1init 或 systemd也就是“孤儿进程”。如果启动的进程是那种长驻服务它就会一直挂在系统里。定时任务重复跑两次或者多次很多时候就是这么来的——上一轮脚本里拉起的后台进程还没退出下一轮启动器又拉了一个新的最终系统里堆了一堆同名进程。想彻底搞清楚进程之间的父子关系常规命令是看 PPID。比如某个可疑进程 PID 是 2345执行ps -o pid,ppid,pgid,sid,cmd -p 2345看 PPID 是谁、再顺着父进程往上翻很快就能画出它完整的族谱。如果 PPID 是 1那就说明它已经是孤儿进程了原本的爹早就退场。这个场景也自然引出“守护进程与会话”的概念。想让一个进程真正脱离终端、脱离父进程独立存活标准做法是让进程调用setsid()或者借助nohup命令让进程忽略 SIGHUP 信号。计划任务里如果确实需要跑一个常驻后台服务比较干净的做法是配合nohup或直接写成 systemd service而不是简单地在脚本里写个就跑。1.3 执行环境差异为什么手动能跑cron 里就报 command not found这是计划任务里最经典、也最让人抓狂的问题。你在终端里执行./backup.sh一切正常把它写进 crontab到点一看日志报xxx: command not found或者脚本里调用的某个命令找不到。问题基本不在脚本本身而在环境变量。用户在终端里登录时shell 会加载/etc/profile、~/.bash_profile等配置文件PATH 里往往被追加了/usr/local/bin、~/bin这些额外路径。而 cron 执行命令时用的是非交互、非登录的 shell它只加载很少的系统配置PATH 通常只剩下/usr/bin:/bin这种基础路径。你脚本里写的是python3、docker、kubectl这些命令的真实可执行文件在/usr/local/bin下PATH 里根本没这个目录自然找不到。解决方式也直接三个思路脚本开头明确export PATH把需要的路径补全这是最常用的做法。crontab 文件顶部写一行PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin让所有任务共享这个环境。命令全部写绝对路径例如/usr/bin/python3 /opt/scripts/backup.py。我个人在实际中更偏爱第 3 种再加一层第 1 种兜底。因为绝对路径能保证“无论什么环境来执行命令都指向同一个文件”这比依赖 PATH 更不容易出幺蛾子。另外要提醒一句脚本本身也得有执行权限或者你在 crontab 里写/bin/bash /opt/scripts/backup.sh绕过执行权限问题。1.4 计划任务和时间的关系比想象中更敏感crond判断到点没有靠的是系统本地时间。这里的坑有两个方向一个是时区不对服务器默认 UTC你以为是北京时间 8 点执行结果它凌晨 8 点UTC 0 点就跑了另一个是系统时间漂移时间慢慢偏了计划任务执行的点也跟着偏位置偏得多了表现就是“任务不按点跑”。这两个问题都不难排查。时区方面看date和/etc/localtime北京时间确认timedatectl里的Time zone是Asia/Shanghai。时间同步方面看timedatectl status里的时间同步状态或者直接执行chronyc tracking。生产服务器上计划任务依赖时间调度时间同步必须开着否则所有定时任务都是“薛定谔的执行”。2. 实操从 crontab 到 systemd timer 的完整落地2.1 crontab 语法与最容易写错的地方先把最基础的五字段格式摆出来字段含义取值范围分第几分钟0-59时第几小时0-23日第几天1-31月第几月1-12周星期几0-70 和 7 都代表周日常用写法可以直接抄*/5 * * * * /usr/bin/bash /opt/scripts/check.sh 0 2 * * * /usr/bin/systemctl restart myapp 30 4 1 * * /usr/bin/bash /opt/scripts/monthly.sh第一行是每 5 分钟跑一次健康检查第二行是每天凌晨 2 点重启应用第三行是每月 1 号凌晨 4 点 30 分跑月度任务。写 crontab 最容易翻车的往往不是语法本身而是几个隐含规则当“日”和“周”同时出现时cron 采用的是“或”逻辑满足其中一个就执行。比如0 0 1 * 7表示的是“每月 1 号执行并且每个周日也执行”不是“每月第一个周日”。想表达“每月第一个周日”cron 原生语法做不了只能自己写脚本判断。%在 crontab 里有特殊含义它会被转换成换行符送到命令的标准输入。也就是说echo %s里的%s会被截断。解决办法是用\%转义或者干脆把命令包进脚本别在 crontab 里写复杂逻辑。命令里的重定向、管道、多条命令看起来能写但一旦写错连带影响的是整条任务。实战中我的习惯是crontab 里尽量只写一条/usr/bin/bash /opt/scripts/xxx.sh具体逻辑全放脚本里。这样调试方便也避免 crontab 语法和环境差异的隐性坑。2.2 输出、日志与重定向给计划任务留一条后路没重定向的计划任务默认输出走的是邮件通道。crond会把任务的标准输出和标准错误发送到 MAILTO 指定的用户邮箱。在大多数没有配置邮件服务的服务器上这就成了一场灾难邮件发送失败、/var/spool/clientmqueue目录不断堆积临时文件、甚至某些版本会出现 crond 反复重试发送拖累服务器性能。所以生产环境里计划任务基本都写成这样*/5 * * * * /usr/bin/bash /opt/scripts/check.sh /var/log/check.log 21这里的21是把标准错误重定向到标准输出当前指向的地方顺序很重要。 /var/log/check.log 21是先让标准输出追加到日志文件再让标准错误跟着标准输出走最终 stderr 也会进到同一个文件。如果顺序反了写21 /var/log/check.log标准错误会先指向终端然后标准输出才改到文件最终 stderr 依然打在终端上文件里只有 stdout排查时就会漏掉真正的报错信息。日志策略上建议一个任务一个日志文件文件名带上脚本名比如check.log、monthly.log。别把所有任务塞进同一个文件否则后期 grep 都不好定位。日志要不要轮转看磁盘空间情况一般配合 logrotate 按天或按大小切割避免日志文件无限增长。2.3 配好计划任务后怎么自检写完 crontab不要拍脑袋就走五分钟做完这套自检# 1. 查看当前用户的任务列表确认写进去了 crontab -l # 2. 确认调度进程在运行 systemctl status crond # CentOS/RHEL 系 systemctl status cron # Debian/Ubuntu 系 # 3. 手动执行一次脚本确认脚本本身没问题 /usr/bin/bash /opt/scripts/check.sh # 4. 查看调度日志确认到点是否真的触发 journalctl -u crond --since 5 minutes ago # 或 CentOS 系看 tail -n 50 /var/log/cron这里有个常见误解修改 crontab 之后要不要重启 crond不需要。crond每次到分钟整点就会重新读取调度表你crontab -e保存后下一分钟它就感知到了。另外注意如果你用了系统级配置目录/etc/cron.d/或/etc/crontab这类文件的格式和用户 crontab 略有区别命令前面多一个用户字段。比如*/10 * * * * root /opt/scripts/clean.sh如果漏了root这个字段任务会被当成无效配置直接跳过而且一些发行版在启动时只会警告一声不仔细看日志很容易忽略。2.4 systemd timer计划任务的进阶形态传统 cron 用了这么多年稳定可靠但它也有明显的短板执行精度只能到分钟、不支持任务依赖关系、资源控制要自己用nice和ulimit凑、日志和 systemd 体系的其余服务不统一。现在的发行版基本都预装 systemd用 systemd timer 来替代 cron 已经是很成熟的做法。它不再是“守候进程拉起子进程”的模式而是由 systemd 直接调度服务单元把计划任务和进程管理两条线合并到了一起。一个 timer 由两个文件组成任务逻辑写在 service 里调度规则写在 timer 里。比如每 5 分钟跑一次检查任务先建/etc/systemd/system/check.service[Unit] DescriptionRun health check script [Service] Typeoneshot ExecStart/usr/bin/bash /opt/scripts/check.sh再建/etc/systemd/system/check.timer[Unit] DescriptionRun health check every 5 minutes [Timer] OnCalendar*:0/5 Unitcheck.service [Install] WantedBytimers.target启用它systemctl daemon-reload systemctl enable --now check.timer用systemctl list-timers可以查看当前所有 timer 的下次执行时间非常直观。systemd timer 对比 cron 的几个核心优势实测下来比较明显调度精度可以到秒级OnCalendar*:*:00/10表示每 10 秒触发。timer 可以配合OnBootSec、OnUnitActiveSec比如开机后 5 分钟执行、距上次执行后隔 10 分钟执行。service 里直接写MemoryMax500M、CPUQuota50%给任务进程套上资源笼头。日志统一进 journaldjournalctl -u check.service一步到位。如果你的服务器已经是 systemd 体系新任务完全可以直接从crontab迁到 timer。老任务不急着全动我一般是在新增任务时优先用 timer等 cron 里的旧任务需要改动时再顺手迁过去逐步切换风险最低。3. 运行态排查找到那个“神秘的进程”3.1 ps 全家桶看清进程的孩子、父亲、户口计划任务跑起来之后最常出现的两个诡异现象一个是脚本跑了没效果另一个是莫名其妙的进程占用资源。遇到这种情况先不要急着改 crontab先用进程视角把现场还原一遍。最基础的是ps -ef看 PID 和 PPID。如果觉得纯列表不够直观用ps -ef --forest它会按父子关系画出树形结果。我曾经排查一个“每隔几分钟服务器多一个代理进程”的问题就是用这条命令定位的进程树的根是crond往下是sh -c再往下才是那个可疑的代理程序。这就证明它不是外部入侵而是有人或者历史配置往 crontab 里塞过一条启动命令。按关键字反查进程用pgreppgrep -af check.sh-a会把完整命令行也打出来方便区分同名脚本。如果同一时间存在多个check.sh进程再补一条for pid in $(pgrep -f check.sh); do ps -o pid,ppid,lstart,cmd -p $pid donelstart是进程精确的启动时间。如果两个进程启动时间相同说明是同一轮任务拉出来的如果启动时间不同说明是相邻两轮任务重叠了——上一轮还没跑完下一轮又启动了。计划任务“任务重叠”非常常见尤其是任务本身执行时间接近调度周期的时候。crond的逻辑就是到点拉起新进程不会主动判断上一轮有没有跑完。解决办法有几种调度周期放宽一点脚本里用flock加文件锁只有拿到锁的进程才继续执行。比如*/2 * * * * /usr/bin/flock -n /var/lock/check.lock /usr/bin/bash /opt/scripts/check.sh-n表示拿不到锁就退出这样脚本还没跑完时下一轮任务会自动放弃进程不会越堆越多。3.2 从日志里把执行路径还原出来日志排查计划任务核心思路是区分“任务没触发”和“任务触发了但执行失败”再进一步判断“脚本秒退了”还是“脚本卡住了”。三种情况对应的现场不一样排查入口自然也不一样。任务没触发先查调度进程本身systemctl status crond再看时间对不对date出来的时间和你预期是否一致。时间没问题就看调度日志CentOS 系在/var/log/cronDebian/Ubuntu 系用journalctl -u cron --since today。日志里会记录每条任务的执行时间点和命令行能清楚看到 crond 到底有没有把任务拉起来。任务触发了但秒退关键看脚本自己的输出日志。刚才说的 /var/log/check.log 21在这里就是救命稻草。如果日志文件空白大概率是命令执行前就报错了比如绝对的路径不对、权限不足、或者 shell 解析失败。把脚本里每段关键逻辑加上echo输出执行到哪一步一目了然。任务卡住了最明显的特征是指定结束时间到了进程还在存活。此时看进程的运行时长和状态top -b -n 1 | head -n 30 ps -eo pid,ppid,stat,wchan:30,cmd | grep check.shwchan能看到进程在内核里的等待点比如卡在pipe_wait、sk_wait_data就是在等子进程或网络数据。结合lsof -p PID看打开的套接字和文件通常能定位它到底等在哪里。3.3 常见计划任务进程问题速查表症状可能原因排查命令解决方式任务到点没执行crond 没运行systemctl status crond启动 crond 并设为开机自启任务到点没执行系统时间漂移/时区不对date、timedatectl status配置 chrony 时间同步修正/etc/localtime任务执行了但报 command not foundcron 环境 PATH 太短在脚本里echo $PATH脚本开头export PATH...或用绝对路径任务执行了但脚本只跑了一半脚本依赖相对路径检查脚本里cd和文件引用方式脚本里先cd /opt/scripts或统一使用绝对路径多个同名进程同时存在任务重叠ps -ef --forest、lstart对比用flock加锁或拉大调度周期杀掉的进程很快又出现周期任务副作用crontab -l检查调度项临时注释对应任务等本周期清完再调整日志目录堆积大量邮件文件未重定向输出邮件发送失败du -sh /var/spool/clientmqueue在 crontab 中加 log 21任务执行但瞬间退出无日志脚本退出码被忽略手动执行脚本捕获退出码脚本末尾加失败重试或日志打印这张表是我平时排障时反复用到的覆盖了绝大多数计划任务诡异现象的根源。遇到问题按表逐条排除基本不会踩空。4. 进程管理实战杀不掉的 PID 与守护化的真相4.1 为什么 kill 掉一个 PID它很快又“长”出来这个现象估计很多同行都遇到过kill -9 PID刚执行完过了几十秒一刷ps好家伙同样的进程又出现了PID 还变了。“杀了一个 PID又来了一个”的思路一定不能只盯着进程本身要看是谁在拉它。计划任务场景里常见原因有三个方向第一个是周期性的 cron 任务。你 kill 掉的只是这一轮拉起来的进程下一分钟crond到点又 fork 一个新的。这就相当于你把地里的草拔了一根但灌溉系统还在定时洒水草当然继续长。应对方式是先看 crontab把这行临时注释掉等下一轮不再生成再去清理正在运行的存量进程。顺序不能反否则前脚杀完后脚新进程又出现你会陷入“杀不完”的循环。第二个是外层有守护性质的父进程或者 while 循环。脚本里如果是一个while true; do ./app; done你 kill 掉app进程外层 shell 会立刻再拉起一个新的。这时的正确做法是杀掉外层进程或者用pkill -f 脚本关键字锁定整条进程链而不是单点去 kill 某个子进程。第三个是它根本就不是 cron 拉起来的而是被 systemd 或者其他服务管理器接管了。如果这个进程对应一个 systemd service并且服务文件里设置了Restartalways那么 kill 后 systemd 会立即重新拉起。处理方法是先停服再禁用systemctl stop xxx.service systemctl disable xxx.service所以“杀不掉的 PID”这个问题的本质是“你只处理了结果没处理原因”。动手之前先用之前讲的ps -o pid,ppid,pgid,sid,cmd把进程的家族关系画出来找到它真正的启动源再动手。另外提醒一句kill -9是最后手段不要一上来就用。先kill默认 SIGTERM给进程优雅退出的机会让它自己关掉文件句柄、清理临时文件处理不了再升级到kill -9。4.2 僵尸进程进程已经把门关上了但还没注销服务器上出现defunct状态的进程时第一反应不要慌。僵尸进程不是病毒它只是子进程已经结束但父进程没有调用wait()来回收它的退出状态导致进程描述符还残留在进程表里。计划任务场景里的僵尸典型来路是用户在脚本里启动了后台子进程但脚本本身快速退出子进程残留。这里展开说一个细节shell 脚本里如果启动了一个后台命令脚本结束时会自动等待这些后台任务吗答案是不会完全对——bash脚本如果简单写./worker 脚本退出后子进程会被 init 收养由 init 负责回收通常不会变成僵尸。但如果父进程还活着、又一直没有wait子进程结束时就容易卡在僵尸状态挂到父进程名下。排查僵尸用ps -A -o stat,ppid,pid,cmd | grep ^Z看到僵尸进程后先看它的 PPID找到父进程。如果父进程是常驻服务重启它僵尸会被回收。如果父进程是 init系统层面一般会自动定期清理不用太担心真正要治本得改脚本在合适位置加上wait让脚本主动回收子进程这对应 Linux 里的wait()/waitpid()机制。从计划任务的角度说脚本设计上尽量避免“fork 出长期子进程然后自己退出”的模式。如果确实需要常驻后台服务把它写成独立的 systemd service由系统接管生命周期比在 cron 里用nohup ... 甩锅要可靠得多。4.3 给计划任务进程装上“笼头”计划任务默认没有任何资源限制脚本里如果写了死循环或者内存黑洞它会一直跑下去直到把 CPU 或内存吃穿。生产环境的计划任务尤其是那些数据处理、批量同步类的任务必须主动加上资源约束。最简单的两招timeout和nice。timeout 300 ./syncdb.sh限制脚本最多跑 5 分钟超时直接杀掉nice -n 10 ./syncdb.sh降优先级让它别和线上服务抢 CPU。配合 crontab 写就是*/10 * * * * /usr/bin/timeout 300 /usr/bin/nice -n 10 /opt/scripts/syncdb.sh /var/log/syncdb.log 21进阶一点用 systemd timer 的 service 单元来做[Service] Typeoneshot ExecStart/opt/scripts/syncdb.sh MemoryMax500M CPUQuota50%MemoryMax限制最大内存CPUQuota限制 CPU 使用率上限超过限制系统自动处理比脚本内部用ulimit挂号更干净。实测下来给计划任务加资源限制的收益非常明显至少不会出现“凌晨一个统计脚本把数据库所在宿主机跑爆”这种事故。脚本内部也可以加ulimit兜底比如ulimit -v 1048576限制虚拟内存为 1GB。但要注意ulimit只对当前 shell 及其子进程生效写在脚本开头才有效。5. 写在最后我的一点排障习惯最后聊点个人经验。做故障复盘时我发现一个规律计划任务的问题表面上千奇百怪绕来绕去都是进程生命周期里的某个环节断了。任务没执行是 crond 没拉起执行失败是 shell 环境不对重复跑是进程重叠没人管kill 掉又出现是启动源没找到。所以我现在排查这类问题的顺序非常固定先画进程树再做日志定位最后才去改配置。别看这顺序简单它能避免大量无效操作尤其是“看着像脚本问题实际是环境问题”的那种情况。还有一个小技巧送给经常和 crontab 打交道的人新写脚本时宁可多写两行日志也别图省事。你永远不知道这个任务半年后会以一个多刁钻的方式失败而日志是你那时唯一的线索。宁可日志冗余也不要裸奔。把这句话想明白维护计划任务这件小事就能给你省下很多个半夜被监控闹醒的觉。