企业官网建设流程全解析

接手一台Linux服务器，第一件让人心里有底的事，就是搞清楚这台机器上到底跑了些什么，以及什么时间该自动去干什么。进程管理和计划任务，这两块东西单独拎出来看都是基础得不能再基础的操作，可实际一上手就发现问题不少：写好的脚本在终端里跑得好好的，放进crontab就一言不发；集群里某个节点突然CPU飙高，你连是哪个进程干的都找不到；半夜一个计划任务把磁盘塞满了，第二天早上才发现。这篇文章我打算把进程和计划任务这两块放在一起讲透，从原理到实操，再把我这些年踩过的坑一并交代出来，希望对正在折腾Linux的朋友有点用处。

1. 先把进程管理的骨架搭明白

进程管理是Linux系统运维的地基，不管是排查性能问题，还是在写脚本时正确处理后台任务，都绕不开进程这个概念。很多人用Linux好几年，ps、top这些命令倒是敲得很顺，可真问起来进程到底是什么、为什么会有僵尸进程、D状态又代表什么意思，一下就被问住了。这一节我先把进程管理的底层逻辑拆开，再一步步带出常用的命令和实操场景。

1.1 进程到底是什么，PID和父子关系先搞清楚

进程说白了就是正在运行的程序实例。程序是硬盘上躺着的一堆二进制文件，进程是操作系统把它加载进内存之后、正在被CPU一条条执行的那个活物。同一个程序可以同时启动多个进程，比如你开了两个终端跑同一个脚本，就有两个独立的进程，它们各自的变量、内存、状态完全隔离，互不干扰，就像同一个剧本被两个不同的演员同时表演，演的虽然是同一出戏，但彼此不共享任何台下的记忆。

每一个进程都有一个唯一的进程ID，就是PID。PID从1开始分配，通常逐渐递增，一个进程结束之后它的PID还可能被后来者复用。Linux系统里的第一个进程是PID 1，也就是systemd（老的SysVinit时代叫init），整个用户空间的所有进程都是它的子孙后代。与PID对应的还有PPID，也就是父进程ID，通过它可以追溯每个进程是从哪里来的。

进程之间的父子关系，最直接的感受就是：你在终端里跑一个命令，这个命令就是当前shell的子进程；你用shell脚本启动了一个服务，服务就是脚本的子进程。有时候你会发现一个进程莫名其妙消失了，可能是它的父进程把它带走了，也可能是父进程先挂掉，它变成了孤儿进程。Linux处理孤儿进程有一套机制，孤儿会被统一收养到PID 1下面，也就是init/systemd管理，这样就不会出现那种完全没人管的野进程。

查看进程树最直观的办法是用ps加一个森林选项，命令是ps -ef --forest，它会用树状缩进展示父子关系。我排查启动脚本问题的时候特别喜欢用这个命令，一眼就能看出service到底是不是由预期进程拉起来的。

1.2 进程状态机：运行、睡眠、停止、僵尸

Linux里的进程不是只有“运行”和“没运行”两种状态，它有一套完整的生命周期，用ps命令看进程时STAT那一列显示的几个字母，就是当前进程的状态码。常见的状态有这些：

初学者最容易困惑的就是僵尸进程和D状态。僵尸进程不是真的还活着，它其实已经执行完了，只是在进程表里留下了一个“已退出但无人收尸”的条目，等待父进程调用wait()来读取它的退出码。如果父进程一直不调用wait，僵尸就一直留在进程表里。僵尸本身不吃CPU也不吃内存，但如果大量堆积，进程号会被耗尽，导致无法创建新进程。

D状态比僵尸更麻烦。进程在等待IO（比如磁盘卡顿、NFS挂载点无响应）时会进入不可中断睡眠，此时你给它发kill -9它都没反应。这类进程通常只能等IO恢复，或者重启系统，没有别的太好办法。我遇到过某云盘挂载点出问题，一堆进程全部卡在D状态，怎么kill都纹丝不动，最后只能把整个挂载点重启。

停下来多看一眼STAT列非常有价值。比如你用ps aux看到一堆Z开头的进程，说明父进程代码有bug，没有正确回收子进程；看到一堆D，就要先检查存储链路。

1.3 常见的进程查看手段与信息解读

排查进程问题，最常用的两个命令是ps和top。ps适合抓快照，一次性看所有进程的静态信息；top适合持续观察，动态刷新CPU和内存占用。两者各有不可替代的作用，配合起来用，基本能满足绝大多数场景。

先聊ps。虽然ps支持很多参数组合，但我实际最常用的是这两个：

• ps -ef：显示所有进程的完整命令行
• ps aux：以BSD风格显示所有进程，包括CPU和内存占用率

对比一下两者的差异：ps -ef不带%CPU和%MEM，ps aux带。但ps aux开头有个奇怪的USER列，加上很多发行版对ps aux的“始终显示进程自身”有历史行为差异，所以我一般推荐用ps -ef --forest拿进程关系，用ps aux看资源占用。

ps aux输出里几个关键字段我举个小栗子来说明：

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1234 0.3 1.2 162144 23000 ? S 09:12 0:02 /usr/sbin/nginx -c /etc/nginx/nginx.conf

VSZ是虚拟内存大小，表示进程可以访问的地址空间大小，单位是KB；RSS是常驻内存大小，表示进程实际驻留在物理内存中的大小。类比一下，VSZ相当于你出门前带上的所有信用卡总额度，RSS才是你真的揣在兜里的现金。看一个进程吃多少内存，重点看RSS。

top就直观多了，默认按CPU占用排序。进入top之后有几个非常常用的交互键：按P按CPU排序，按M按内存排序，按k可以给进程发信号，按c可以展开完整命令行，按1可以看每个CPU核心的负载。还有个更容易入门的htop，有颜色有树状视图，甚至可以直接鼠标操作，适合不习惯纯键盘交互的朋友。不过很多生产环境没有预装htop，建议还是把top练熟，起码到任何机器上都能直接用。

提到性能排查，还有一个被系统管理员低估的命令叫pidstat，它是sysstat包里的工具。比如你想看看某个进程5分钟内的CPU波动，用pidstat -p PID 1 300就能每秒采集一次、采集300次，然后自己看趋势。跟top相比，pidstat更适合脚本化监控和导出数据。

2. 进程管理实操：从命令行到脚本

看懂进程状态只是第一步，真正考验功力的地方是实际动手管理进程，尤其是处理前台后台切换、让服务在终端关闭后继续存活、调整优先级，还有最考验自己的杀进程。这些操作看似一个个分散的小命令，但在真实环境下组合出问题的情况特别多，我挨个讲。

2.1 前台任务与后台任务的切换技巧

在终端窗口里直接执行的命令就是前台任务，它会一直占着这个终端，直到执行完毕。假如你启动了一个需要长时间运行的命令，比如一个大文件的压缩解压，或者一个临时起的长任务Web服务，整个终端就被卡住了，其他命令都敲不了。这时候怎么办？很多人第一反应是再开一个终端窗口。其实完全不用，Linux早就为这种情况设计好了前后台切换机制。

在任务运行过程中按Ctrl+Z可以把它挂起，此时进程会进入T状态（stopped），任务停在那里等你后续处理。挂起之后你会回到shell提示符，这时候可以继续敲其他命令，也可以用jobs查看所有被挂起的任务列表。jobs输出第一列的中括号数字就是job号，比如[1]、[2]。

想把某个挂起的任务拉回前台继续运行，用fg %任务号；想让它在后台继续跑，用bg %任务号。直接举例：

[root@localhost ~]# sleep 300 ^Z [1]+ 已停止 sleep 300 [root@localhost ~]# jobs [1]+ 已停止 sleep 300 [root@localhost ~]# bg %1 [1]+ sleep 300 & [root@localhost ~]# ps -ef | grep sleep

注意Ctrl+Z挂起的进程和后台进程是两回事。后台进程是直接通过&符号启动的，比如sleep 300 &，它本来就在后台运行；Ctrl+Z挂起只是暂停，让它继续运行得用bg切换。

在这里有个非常容易踩的坑：后台进程虽然不在前台占着终端，但它的输出还是会直接打到当前终端上，而且当你在同一个终端里执行了exit退出shell时，后台进程通常会收到SIGHUP信号直接被杀掉。想让进程彻底不受终端生命周期影响，得用下面讲的nohup或者setsid。

2.2 让进程脱离终端的正确姿势

后台运行并不等于守护进程化，这是很多刚接触Linux的人最大的误解。用sleep 300 &启动的进程，虽然终端看起来解放了，但它仍然是当前shell的子进程，shell退出时给所有子进程发SIGHUP信号，这个后台进程大概率就跟着没了。要验证这个现象很简单：你在一个终端里启动后台任务，然后退出终端，重新登录后发现进程已经不存在了。

要让任务在终端关闭后继续存活，有几个成熟的办法。

第一个是nohup，全称no hang up，专门用来忽略SIGHUP信号：

nohup /opt/app/run.sh > /var/log/app/run.log 2>&1 &

nohup + &是经典组合。nohup保证进程不响应SIGHUP，&让它放到后台。命令最后的> /var/log/app/run.log 2>&1把标准输出和标准错误都重定向到同一个日志文件里，不然nohup会默认生成一个nohup.out文件放在当前目录，时间一长容易把目录搞乱。

第二个是setsid，它直接让进程开启一个新的会话，彻底脱离当前控制终端。场景上比nohup更干净，不用理会SIGHUP的问题，因为进程连会话都换掉了。不过实际使用中，nohup足够覆盖绝大多数需求，setsid主要用在那种需要双fork守护进程化、对环境有洁癖的场景。

第三个是disown，它是shell内建命令，把已经启动的后台任务从shell的任务表中移除，这样shell退出时就不会给它发SIGHUP信号了。用法是：

sleep 300 & disown -h %1

注意disown一定要在任务启动之后、shell退出之前执行，它管不了已经开始逃跑的进程。我个人的习惯是：临时后台跑东西用nohup，写systemd服务用服务文件管理，这两个套路最不容易出幺蛾子。

2.3 进程优先级与资源限制调整

Linux是一个多任务系统，CPU时间片怎么分配，很大程度取决于进程的优先级。优先级在ps -l命令输出里对应PRI列，在top里对应PR列和NI列。NI就是nice值，取值范围从-20到19，默认是0。nice值越小，优先级越高，越容易抢到CPU时间片；nice值越大，优先级越低，越谦让。

普通用户只能把nice值调大，也就是让优先级变低，不能调小，因为调小会影响其他用户的公平性。root用户则可以任意调整。启动命令时直接设置优先级用nice命令，对已经运行的进程调整用renice命令：

# 以较低优先级启动压缩任务 nice -n 10 tar czf /data/backup/$(date +%F).tar.gz /data/app # 修改已有进程的nice值 renice -n 15 -p 12345

实际运维中，你会用到这个功能的典型场景是：一台服务器上既有线上服务，又有临时数据压缩任务，如果不调整优先级，压缩任务很可能把CPU都吃光，导致线上接口响应变慢。我给这类任务设计规范时，一般要求所有批处理任务必须显式设置nice值，禁止裸奔启动。

top里按r键可以交互式renice一个进程，会提示你输入PID和nice值。这个操作适合临时性调整，如果是一个长期存在的服务，应该写进systemd服务配置里的Nice字段，稳定可控。

2.4 杀进程的正确姿势：先学会确认再动手

进程管理里最危险的操作就是杀进程，尤其在生产环境。我见过太多因为杀错进程导致线上事故的情况，大多数都是因为没确认清楚就在那里kill -9。这里不夸张地说，kill命令用好了是利器，用不好就是灾难。

Linux的信号不止SIGKILL（9号）一个，但很多人下意识只会kill -9。其实每个信号都有它该用的场景，关键是要理解进程收到信号后的反应：

为什么要先用SIGTERM而不是直接上SIGKILL？因为SIGTERM给了进程执行清理动作的机会，比如保存状态、释放锁、关闭文件描述符，很多服务都能在收到SIGTERM时正常退出。SIGKILL是直接从内核层面干掉进程，进程完全没有反应时间，你kill掉的可能是它正在写一半的文件，也可能是它正准备落盘的数据库事务。

我总结的杀进程安全流程是三步：

1. 确认目标。不管是ps、pgrep还是top，先把要杀的进程PID和命令行看清楚，最好能看一眼父进程和子进程关系。
2. 先温和后暴力。先kill（默认SIGTERM），等几秒，观察进程还在不在，再决定要不要kill -9。
3. 杀完验证。ps确认进程确实消失，端口确实释放，关联服务没有异常。

另外要特别提醒pgrep -f这个匹配的坑。pgrep -f是对完整命令行做模糊匹配，一旦你匹配的字符串写宽了，很容易把一堆不相关的进程一起匹配上。比如你想杀的是跑在/tmp/test.sh的脚本，写了pgrep -f test，结果把名字里包含test的所有进程全杀了。我的习惯是pgrep -a先列出匹配到的所有PID和命令行，确认无误再kill。

3. 计划任务的核心：cron这件事怎么玩明白

进程管理管的是“现在跑什么”，计划任务管的是“到什么时间自动跑什么”。Linux系统里最传统也最通用的计划任务工具就是cron，几乎每个发行版都带。cron本身不复杂，但配置里到处是细节，写错一个语法、漏了一个环境变量，任务就安安静静地不出声了。这一节从机制到实操，把cron撸明白。

3.1 cron的工作机制与两条配置线

crond是Linux的后台守护进程，它每分钟醒来一次，检查当前时间是否匹配某个计划任务的配置，匹配就触发对应命令。这个“每分钟检查一次”的机制决定了cron的精度只有分钟级，你想让任务每秒执行一次，写在crontab里是实现不了的，得靠脚本内部循环或者别的工具。

配置计划任务有两条线：系统任务和用户任务。系统级别的任务写在/etc/crontab文件里，以及/etc/cron.d/目录下；用户级别的任务用crontab -e编辑，存储在/var/spool/cron/目录下，每个用户对应一个文件。

很多人分不清/etc/crontab和crontab -e的区别，这里说清楚：/etc/crontab是系统配置文件，它比用户crontab多了用户字段，格式上需要指定以哪个用户身份执行命令。直接搬个例子：

# 系统crontab示例，命令前面要写用户名 0 3 * * * root /usr/local/bin/backup.sh # 用户crontab示例，不需要写用户名 0 3 * * * /usr/local/bin/backup.sh

大多数个人的、按用户隔离的任务，用crontab -e就足够；涉及到需要在机器上统一管理的系统级任务，比如日志清理、监控采集，放/etc/cron.d/目录里更合适，因为运维脚本可以通过配置管理工具统一部署这个目录下的文件，不用挨个用户去改。

另外还有个快速使用技巧：crontab -l查看当前用户的计划任务，crontab -r清空当前用户的计划任务（这个操作没有默认确认提示，一旦误触全没了，慎用），crontab -u用户名可以管理其他用户的任务（仅限root）。

3.2 crontab时间字段到底怎么填

crontab的语法是五段式时间加命令，看起来很简单，但坑就藏在细节里：

分 时 日 月 周 命令

五个字段分别表示：分钟（0-59）、小时（0-23）、日期（1-31）、月份（1-12）、星期（0-7，0和7都表示周日）。每个字段还支持星号（所有可能的值）、逗号（枚举多个值）、减号（范围）、斜杠（步长）。

下面这几个写法是最高频的，建议直接背下来：

# 每天凌晨2点30分执行 30 2 * * * /usr/local/bin/backup.sh # 每10分钟执行一次 */10 * * * * /usr/local/bin/check.sh # 每周一到周五早上9点执行 0 9 * * 1-5 /usr/local/bin/report.sh # 每月的1日和15日的3点执行 0 3 1,15 * * /usr/local/bin/clean.sh # 每两小时执行一次 0 */2 * * * /usr/local/bin/health.sh

斜杠前面如果省略，其实就是从范围最小值开始按步长走。/10的意思是每10分钟，如果要每35分钟，写/35就能实现吗？不能，因为*/35只会在0、35分执行，不是每35分钟执行，因为小时位不会跟着调整。很多新手在这里被坑过，产生“为什么我的任务怎么只在整点和35分跑？是不是坏了”的疑问。

还有一个非常经典的易错点：日和星期同时指定时，cron的处理逻辑是“或”关系，而不是“且”关系。比如下面这个写法：

0 0 1 * 1

这个任务会在每月的1号执行，同时还会在每个周一执行，而不是“只有既是1号又是周一才执行”。如果你想让任务只在每月1号（不管周几）执行，把周字段写成星号；想让任务只在周一执行且必须是当月的某种条件，就得在脚本里做日期判断。

3.3 用实际案例写出可落地的计划任务

光会填字段还不够，真正写出来的计划任务要能稳定运行几个月不炸，才算合格。我拿三个最常见的场景举例子，你基本可以照着改。

第一个是日志清理。应用日志增长很快是常事，用磁盘空间报警前就把旧日志清掉。

# 每天凌晨3点清理7天前的应用日志 0 3 * * * find /data/log/app -name "*.log" -mtime +7 -exec rm -f {} \;

这里mtime +7表示修改时间超过7天。把清理动作放到find的-exec里而不是管道后面，可以避免文件名带空格导致的分词问题。不过这种方式如果日志文件特别多，执行时间会比较长，我见过日志量大的机器上这个命令跑了十几分钟，建议量大的场景写成脚本，用find配合循环分批删。

第二个是数据备份。直接想当然地在crontab里写备份命令会埋雷，因为备份脚本通常依赖数据库客户端、压缩工具、环境变量，这些在cron环境里都不一定好使。正确的姿势是写一个独立脚本，然后crontab只负责调脚本：

# 每天晚上2点执行数据库备份脚本 0 2 * * * /usr/local/bin/mysql_backup.sh

备份脚本内部要包含完整的逻辑：进入备份目录、执行导出、压缩、清理7天前的旧备份、记录日志。脚本开头最好显式设置所需要的PATH变量，比如export PATH=/usr/local/mysql/bin:/usr/local/bin:/usr/bin:/bin，然后再执行命令，否则很可能出现“交互终端里跑得好好的，crontab一执行就报command not found”。

第三个是接口健康检查。定时探测某个HTTP接口，失败时发提醒。这个在crontab里写一行命令就能对付：

# 每5分钟检查接口状态，失败时触发告警脚本 */5 * * * * curl -fsS http://127.0.0.1:8080/health || /usr/local/bin/alert.sh

curl的-f参数在HTTP错误码时失败，-s静默模式，-S出错时显示错误信息。配合||逻辑，接口挂掉时执行告警脚本。注意这里告警脚本要事先确认它的执行路径是绝对路径，不能用相对路径。

3.4 计划任务的权限与安全控制

crontab不是每个人都能随便用的。系统管理员可以通过/etc/cron.allow和/etc/cron.deny两个文件控制哪些用户可以创建计划任务。如果两个文件都不存在，默认逻辑因发行版而异，有些系统只有root能使用crontab，有些系统所有用户都可以。生产环境建议只保留cron.allow文件，里面显式列出允许使用的用户名，这样权限边界最明确。

更需要在意的安全细节是：root的crontab权限实在太大，能执行任何命令。所以我们应该尽量以最小权限运行计划任务，能用普通用户跑的任务就不要用root。比如备份脚本如果只需要读数据库的特定库，就用专门创建的备份账号，不要用root账号连数据库。

另外还要提防计划任务被利用来提权：如果你有任何目录对普通用户可写，而root的计划任务恰好会执行这个目录下的脚本，普通用户就能替换脚本内容来获取root权限。这类安全隐患在安全加固检查里属于高频问题，我的习惯是所有被crontab引用的脚本目录，权限一律设为750以上，属主设为root，杜绝被低权限用户篡改。

4. 计划任务不执行？这套排查思路送给你

几乎每个用cron的人都会遇到“任务没跑”的灵异事件。实际上cron的灵异事件90%都是可以快速定位的，只是很多人排查时没有完整的思路，东看一下子、西摸一下子，浪费时间还找不到问题。我按排查顺序整理了一套方法，按这个流程走一遍，基本都能水落石出。

4.1 先看服务状态、再来一遍日志

任务没执行，第一件事是确认crond服务本身是活着的。systemd环境下执行systemctl status crond，确认是active (running)。在容器或者精简环境里，crond经常没有被安装或者没有启动，这是最常见的原因之一。

服务正常，再看cron日志。日志位置在多数发行版上是/var/log/cron。用tail命令看最近记录：

tail -n 200 /var/log/cron

日志里每一行对应一次任务触发，大致长这样：

Dec 15 03:00:01 hostname CROND[12345]: (root) CMD (/usr/local/bin/backup.sh)

关键在于：如果日志里都没有这一行，说明crond根本没匹配到这条配置，问题出在时间字段或者crontab文件本身；如果日志里有CMD记录，但任务看起来没生效，问题就出在脚本执行部分。

还有一种情况是cron执行了但脚本报错，比如权限不够、命令不存在，这些信息默认不会进cron日志，而是通过邮件发送给当前用户，或者被丢弃。系统上如果没配置邮件服务，你又没做输出重定向，错误就被吞了，这也是“任务消失了”的最大原因之一。

4.2 环境变量和路径问题是最大坑

终端里手动执行脚本一切正常，放到cron里就是不行，排到最后的元凶十有八九是环境变量。cron执行命令时的PATH是非常精简的，通常只有/usr/bin:/bin，而你交互shell里的PATH可能带着/usr/local/bin、/opt/xx/bin等一堆自定义路径。于是，脚本里直接用python3、java，cron环境下就变成command not found。

解决方式有两种，我觉得都要做：

第一，脚本内部开头设置PATH。比如：

#!/bin/bash export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

第二，脚本内部所有命令尽量写绝对路径，或者把关键工具路径定义成变量再用。比如MYSQL=/usr/local/mysql/bin/mysql，然后调用$MYSQL。这样做的好处是脚本不会再因为PATH不同而行为分裂。

还有一个坑：cron不会加载你的shell配置文件，没有~/.bash_profile，没有~/.bashrc。如果脚本依赖一些自定义环境变量，比如JAVA_HOME、ORACLE_HOME，这些是不会自动进入cron环境的。要么在脚本里重新export，要么用source命令把配置文件加载进来，但加载配置有副作用，可能引入一堆用不到的东西，我的习惯是宁可脚本里显式写自己需要的那几个变量，不让它全量加载。

4.3 百分号转义和输出重定向的小细节

crontab配置文件里%是有特殊含义的，%在cron中会被解释为换行符。如果你直接在crontab命令行里写date +%Y%m%d，执行结果会完全不对，因为这个%会让后面的内容变成换行。正确写法是把它转义成%：

# 错误写法，输出会异常 0 2 * * * tar czf /data/backup/$(date +%Y%m%d).tar.gz /data/app # 正确写法 0 2 * * * tar czf /data/backup/$(date +\%Y\%m\%d).tar.gz /data/app

这是新手最容易踩的坑：在终端里测试明明好好的，一放进crontab，文件名就变成了乱七八糟的样子。或者更简单的方法，把整个逻辑写进脚本，日期在脚本里用正常的$(date +%Y%m%d)，这样crontab里避开了%号的解析问题。

另一个绝对值得养成习惯的是输出重定向。cron中如果任务有标准输出或标准错误输出，默认会以本地邮件形式发给当前用户邮箱。服务器上通常没有完整邮件系统，这些邮件会堆积在/var/mail/用户目录下，时间长了占空间不说，出了问题想看也麻烦。正确做法是把输出重定向到日志文件：

0 3 * * * /usr/local/bin/cleanup.sh >> /var/log/cleanup.log 2>&1

这样执行日志长期落盘，出问题随时可以回头查。如果脚本本身不产生输出但对执行成功状态有要求，可以在脚本内通过exit code判断，cron的机制是只看exit code为0才算成功，否则会向用户发邮件。

4.4 一次性任务的替代方案：at与systemd定时器

cron适合周期性任务，但在“几小时后执行一条命令”“今天下午4点跑一下脚本”这种一次性场景里就不合适，这时候用at命令更顺手。

# 下午4点执行 at 16:00 > /usr/local/bin/deploy.sh > 按Ctrl+D结束输入 # 查看等待中的任务 atq # 删除指定编号任务 atrm 5

at本身的原理也是后台守护进程atd，每秒钟检查一次任务队列，精度比cron高很多。不过生产环境我还是建议大家尽量少依赖at，因为一次性任务容易遗漏，不便于自动化审计。

新一代计划任务首选其实是systemd timer。它比cron多了几个优势：任务执行状态可以在systemd的日志体系里统一管理（journalctl查看），可以声明服务依赖，可以为错过的定时任务做持久化补执行（Persistent=true，比如系统关机时任务没跑，开机后自动补上），还能设置随机延时防止多台机器同时执行造成服务器冲击。缺点是配置比crontab多几个文件，难记一些。

一个最简单的systemd timer需要两个文件：服务单元和定时器单元。比如/usr/local/lib/systemd/system/backup.service和backup.timer，service里写明要执行的命令，timer里用OnCalendar=指定时间，再用systemctl enable --now backup.timer启动。之后日常管理用systemctl status backup.timer就能看到上次触发时间、下次触发时间、最近执行结果，体验比cron全靠日志猜来得好。

5. 实战经验合集：进程和计划任务联动避坑指南

前面讲的是各模块的知识，但真实运维里进程和计划任务常常是一对搭档：计划任务半夜启动了批量任务，批量任务跑挂了一堆子进程或者导致系统负载飙升；你排查时又发现杀不掉的进程其实是计划任务反复拉起来的。这一节把我实际用过、多次验证过的综合案例和习惯沉淀出来，照这个思路走，能省掉大量无谓的折腾。

5.1 几个真实场景复盘：半夜备份抢CPU、僵尸堆积、任务重叠

先讲一个最典型的场景：备份。备份通常是凌晨低峰期跑的，但低峰期不是没业务，很多服务的夜间批处理任务也在跑。如果你备份脚本启动压缩任务的时候不设置nice值，而且服务器CPU核心数不多，备份任务很可能把负载直接拉满，导致线上服务夜间也能感知到延迟。我的解决方案是备份命令统一加nice调低优先级，同时用ionice限制磁盘IO优先级，让备份任务“谦让”着跑：

nice -n 10 ionice -c2 -n7 tar czf /data/backup/$(date +\%F).tar.gz /data/app

第二个场景是僵尸进程堆积。如果某台机器长期运行着一个有bug的父进程，它不停地创建子进程但从不回收，进程表里Z状态就会越堆越多，pid_max到达上限后任何新进程都起不来。处理方法是先定位僵尸进程的父进程是谁，ps -ef | grep defunct能看到僵尸进程的PID和PPID，确认父进程后把它停掉或者重启，然后系统init进程会把僵尸的退出信息回收调。杀僵尸本身没用，僵尸是杀不死的，根子在父进程。

第三个场景是任务重叠。计划任务本身执行时间超过周期，上一个还没跑完，下一个又启动了。比如日志清理任务是每5分钟一次，但某次日志量爆炸导致单次清理耗时10分钟，你就同时在跑两个清理进程，互相抢文件、重复加锁，最终把磁盘IO拖垮。解决方式是在脚本内部加锁，业界比较通用的做法是用flock：

#!/bin/bash exec 200>/var/lock/cleanup.lock flock -n 200 || { echo "[$(date)] 已有实例在运行，本次跳过" >> /var/log/cleanup.log exit 1 } # 实际清理逻辑 find /data/log -name "*.log" -mtime +7 -delete

这样同一时间只有一个清理进程能拿到锁，抢不到锁的实例直接退出，不会发生并发冲突。

5.2 让计划任务更稳的三个习惯

既然计划任务是无人值守的，就更需要在设计上保证它遇到问题时不会把环境搞得更糟。我总结下来有三个习惯对稳定性影响最大。

第一，脚本里必须设置超时控制。一条命令卡住不退出，在手动场景你还能Ctrl+C，在cron场景它就是一直挂着，占用进程和资源。我习惯用timeout命令包一层：

# 最多跑30分钟，超时就杀掉并记录异常 timeout 1800 /usr/local/bin/backup.sh

timeout执行完还会返回124退出码，可以在外壳层判断是否是超时退出，再做额外告警。

第二，所有输出都要留痕。不管成功失败，执行完把结果写到日志里，最好是“固定路径 + 日期后缀”的方式，历史记录按天保留。清理日志的老化策略再配合cron自己来清，就形成了一个闭环。我最常见的一个败笔就是早期写脚本从不打日志，出了问题完全不知道脚本执行到哪一步，只能靠猜。

第三，做幂等设计。一个计划任务重复执行两次，结果应该是一致的，不能因为上一次的残留状态导致第二次执行出错。比如备份脚本如果检查到备份目录已经存在同名文件，要么覆盖要么跳过，不能直接中断；清理脚本如果发现日志目录不存在，应该正常退出而不是报错。幂等性是非交互脚本的安全底线。

5.3 把进程快照和计划任务结合起来做监控

最后分享一个我觉得特别实用的小技巧：用计划任务周期性采集进程快照，留作事后排查依据。

具体做法是写一个收集脚本，每隔一段时间把关键进程的CPU、内存、线程数、进程树信息追加到当日快照文件：

#!/bin/bash SNAPSHOT_DIR=/var/log/process_snapshot mkdir -p "$SNAPSHOT_DIR" SNAPSHOT_FILE="$SNAPSHOT_DIR/snapshot_$(date +\%F).log" { echo "===== $(date '+%F %T') =====" ps -eo user,pid,ppid,pcpu,pmem,stat,etime,cmd --sort=-pcpu | head -n 30 echo "----- 进程总数统计 -----" ps -e | wc -l echo "----- 僵尸进程列表 -----" ps -ef | awk '$3 ~ /Z/ {print}' || true } >> "$SNAPSHOT_FILE" # 清理30天前的快照 find "$SNAPSHOT_DIR" -mtime +30 -name "*.log" -delete

crontab里配置每5分钟执行一次。等某天出了性能问题，你就能翻出事情发生那一刻的进程快照，谁在吃CPU、有没有僵尸、进程数量是不是突然暴涨，一目了然。这个习惯在排查“凌晨3点CPU飙高”这类问题时尤其能救命。

根据我个人的操作习惯，我还会在上面脚本里额外记录系统load average和内存占用两个指标，这样快照里的信息更完整，排查时能少跳好几个来回。既然快照是定时采集的，建议同一台机器上的采集时间错开整点，比如用1、6、11、16分这样的随机偏移，避免多台机器同时采集造成监控数据采集端的短时压力。

这篇文章写到这里，进程和计划任务这两块的核心玩法也算铺完了。跟很多东西一样，知道命令容易，难的是组合起来形成自己的一套习惯。我觉得最好的练习方式不是去背各种参数，而是真的找一台机器，故意把crond停掉一次，故意写一个带%号的计划任务，再故意用一个不带权限的脚本放进去，然后按日志一步步把问题揪出来。栽过跟头之后，这些东西就是你的肌肉记忆了。