## 背景

前一阵子把 [CodeBuddy CLI + Open-IM](https://cloud.tencent.com/developer/article/2672805) 部署到了腾讯云 Lighthouse 服务器上，实现了飞书消息 → CodeBuddy AI 的桥接。最近想让它支持定时任务，自动在每周三早上推送 xxx 定时任务。

方案是标准的：`npm install node-cron`，新增 `dist/scheduled-tasks/` 目录下的 scheduler、task-runner、task-config 三个模块，改 `dist/index.js` 启动/停止注册，改 `dist/config.js` 加载 `scheduledTasks` 字段，`config.json` 加入 `eda-weekly` 任务定义。

改完 `systemctl restart open-im`，然后——服务开始反复重启。

这篇文章记录我从接到问题到定位根因、修复验证的完整过程，希望能给遇到类似问题的朋友一个可复用的排查思路。

---

## 一、现象观察

首先看 systemd 日志：

```bash
systemctl status open-im
journalctl -u open-im -n 50 --no-pager
```

关键发现：

```
Jun 21 21:26:32 open-im.service: Scheduled restart job, restart counter is at 1.
Jun 21 21:59:13 open-im.service: Scheduled restart job, restart counter is at 2.
Jun 21 22:00:53 open-im.service: Scheduled restart job, restart counter is at 3.
Jun 21 22:05:22 open-im.service: Deactivated successfully.
```

`RestartSec=5` 配合 systemd 默认的 `StartLimitBurst=5`（30 秒内最多重启 5 次），服务在经历 3 轮重启后最终被 systemd 保护机制停掉了。

**第一反应：代码有 bug，node 进程启动后 crash 了。**

但真的是这样吗？

---

## 二、先确认环境，别猜

在排查之前，需要搞清楚几个基本事实：

```bash
# 1. 安装位置
npm list -g @wu529778790/open-im
# → @wu529778790/open-im@1.10.8
# → 路径：/root/.nvm/versions/node/v22.22.2/lib/node_modules/@wu529778790/open-im/

# 2. systemd 服务定义
cat /etc/systemd/system/open-im.service
```

服务定义的关键部分：

```ini
[Service]
Type=simple
WorkingDirectory=/root/.openclaw/workspace
ExecStart=/root/.nvm/versions/node/v22.22.2/bin/node \
  /root/.nvm/versions/node/v22.22.2/lib/node_modules/@wu529778790/open-im/dist/cli.js dev
Restart=always
RestartSec=5
StandardOutput=append:/root/.open-im/logs/restart.log
StandardError=append:/root/.open-im/logs/restart.log
```

好消息：日志已经配置了 `append` 到文件，不需要去 `journalctl` 翻。

---

## 三、看日志，找线索

```bash
cat /root/.open-im/logs/restart.log | tail -100
```

日志中出现了关键信息：

```
2026-06-21 21:26:33 [INFO] [Scheduler] Task eda-weekly ("xxx") scheduled: 3 8 * * 3 on feishu
2026-06-21 21:59:06 [INFO] [Scheduler] Stopped 1 scheduled task(s)
2026-06-21 22:05:19 [INFO] [Main] Shutting down...
2026-06-21 22:05:19 [INFO] [Scheduler] Stopped 1 scheduled task(s)
```

**重要发现：**

1. `Scheduler` 日志出现了 — 说明新增的定时任务代码**确实被执行了**
2. `Stopped 1 scheduled task(s)` 出现 — 说明 shutdown 流程被触发，scheduler 正常清理
3. **日志中没有 crash 堆栈** — 没有 `Error:`、没有 `throw`、没有 `Cannot find module`

这意味着：**不是代码崩溃导致的重启，而是有人（或 systemd）在反复 stop/start 服务。**

继续看最后一条日志时间戳停在 `22:05:22`，与 `systemctl status` 中的 `inactive (dead) since Sun 2026-06-21 22:05:22` 完全吻合。

---

## 四、验证代码完整性

虽然日志指向"手动 stop"，但还是要排除代码问题。检查改动点：

### 4.1 确认新增文件存在

```bash
ls -la /root/.nvm/.../open-im/dist/scheduled-tasks/
# scheduler.js
# task-config.js
# task-runner.js
# trigger.js
```

### 4.2 确认依赖安装

```bash
ls /root/.nvm/.../open-im/node_modules/ | grep cron
# node-cron ✅
```

### 4.3 确认 config.js 改动

```bash
grep -n "scheduledTasks" /root/.nvm/.../open-im/dist/config.js
# 505: scheduledTasks: file.scheduledTasks ?? [],
```

### 4.4 确认 index.js 改动

```bash
grep -n "scheduled\|scheduler\|Scheduler" /root/.nvm/.../open-im/dist/index.js
# 35:  import { initScheduler } from "./scheduled-tasks/scheduler.js";
# 256: // Initialize scheduled tasks (cron)...
# 266: const schedulerHandle = initScheduler({...});
# 315: schedulerHandle?.stop();
```

所有改动点完整，且与官方源码的架构兼容。

### 4.5 验证 cron 表达式

```bash
cd /root/.nvm/.../open-im
node -e "const cron = require('node-cron'); console.log(cron.validate('3 8 * * 3'))"
# true ✅
```

---

## 五、核心代码回顾

以下是我新增的三个模块的核心逻辑：

### scheduler.js — 注册 & 生命周期管理

```javascript
import cron from 'node-cron';
import { validateScheduledTasks } from './task-config.js';
import { createTaskRunner } from './task-runner.js';
import { createLogger } from '../logger.js';

const log = createLogger('Scheduler');

export function initScheduler(deps) {
    const { config, sessionManager, platformRunningTasks, sendTextReply } = deps;
    const tasks = validateScheduledTasks(config.scheduledTasks);
    const jobs = [];

    if (tasks.length === 0) {
        log.info('No scheduled tasks configured');
        return { stop: () => {} };
    }

    const taskRunner = createTaskRunner({
        config,
        sessionManager,
        runningTasks: platformRunningTasks.get('feishu') ?? new Map(),
        sendTextReply,
    });

    for (const task of tasks) {
        if (!task.enabled) continue;
        if (!cron.validate(task.schedule)) {
            log.error(`Task ${task.id} has invalid cron schedule: ${task.schedule}`);
            continue;
        }
        const job = cron.schedule(task.schedule, async () => {
            log.info(`[task=${task.id}] Cron fired: ${task.schedule}`);
            const delays = [0, 5_000, 15_000, 60_000];  // 重试退避策略
            for (let attempt = 1; attempt <= 3; attempt++) {
                if (attempt > 1) {
                    await new Promise((r) => setTimeout(r, delays[attempt - 1]));
                }
                const ok = await taskRunner.run(task);
                if (ok) break;
            }
        });
        jobs.push(job);
        log.info(`Task ${task.id} ("${task.name}") scheduled: ${task.schedule}`);
    }

    return {
        stop: () => {
            for (const job of jobs) job.stop();
            log.info(`Stopped ${jobs.length} scheduled task(s)`);
        },
    };
}
```

设计要点：
- 统一生命周期：`init` 返回 `{ stop }`，与 open-im 原有的 platform 模块接口一致
- 重试策略：3 次重试，退避间隔 5s / 15s / 60s
- 参数校验：cron 表达式和任务配置双重校验，格式错误的任务自动跳过

### task-runner.js — 复用 AI pipeline

```javascript
import { getActiveChatId } from '../shared/active-chats.js';
import { createPlatformAIRequestHandler } from '../platform/handle-ai-request.js';
import { createLogger, emitStructuredEvent } from '../logger.js';

const log = createLogger('TaskRunner');

export function createTaskRunner(deps) {
    const { config, sessionManager, runningTasks, sendTextReply } = deps;

    async function run(task) {
        const chatId = getActiveChatId(task.platform);
        if (!chatId) {
            log.warn(`[task=${task.id}] No active chatId, skipping`);
            return false;
        }

        const userId = `scheduled:${task.id}`;  // 虚拟用户，隔离 session
        const handleAIRequest = createPlatformAIRequestHandler({
            platform: task.platform,
            config,
            sessionManager,
            sender: {
                sendThinkingMessage: async () => `scheduled:${task.id}:no-thinking`,
                sendTextReply: async (_chatId, text) => {
                    await sendTextReply(task.platform, chatId, text);
                },
                startTyping: () => () => {},
            },
            throttleMs: 2000,
            runningTasks,
            taskKeyBuilder: (uid, _msgId) => `${uid}:scheduled`,
            taskCallbacksFactory: ({ chatId: c }) => ({
                streamUpdate: async () => {},
                sendComplete: async (content) => {
                    await sendTextReply(task.platform, c, content);
                },
                sendError: async (error) => {
                    await sendTextReply(task.platform, c, `定时任务 ${task.id} 执行失败: ${error}`);
                },
            }),
        });

        try {
            await handleAIRequest({
                userId, chatId, prompt: task.prompt,
                workDir: sessionManager.getWorkDir(userId) || process.cwd(),
                convId: `scheduled:${task.id}`,
            });
            return true;
        } catch (err) {
            log.error(`[task=${task.id}] Failed:`, err);
            return false;
        }
    }

    return { run };
}
```

设计要点：
- **复用而非重造**：直接调用 `createPlatformAIRequestHandler`，与真实用户消息走完全相同的 AI pipeline
- **虚拟用户隔离**：`userId = scheduled:<task.id>`，确保 session 和请求队列与真实用户不冲突
- **结果回传**：通过 `sendTextReply` 将 AI 输出推送回飞书

### task-config.js — 配置校验

```javascript
import { createLogger } from '../logger.js';

const log = createLogger('TaskConfig');

export function validateScheduledTasks(raw) {
    if (!Array.isArray(raw)) return [];
    const tasks = [];
    for (const item of raw) {
        if (!item || typeof item !== 'object') continue;
        const errors = [];
        if (typeof item.id !== 'string' || !item.id) errors.push('id must be non-empty string');
        if (typeof item.schedule !== 'string' || !item.schedule) errors.push('schedule must be non-empty string');
        if (typeof item.prompt !== 'string' || !item.prompt) errors.push('prompt must be non-empty string');
        if (typeof item.platform !== 'string' || !item.platform) errors.push('platform must be non-empty string');
        if (errors.length > 0) {
            log.warn(`Skipping invalid task ${item.id ?? '(unknown)'}: ${errors.join('; ')}`);
            continue;
        }
        tasks.push({
            id: item.id,
            name: typeof item.name === 'string' ? item.name : item.id,
            schedule: item.schedule,
            platform: item.platform,
            prompt: item.prompt,
            aiCommand: typeof item.aiCommand === 'string' ? item.aiCommand : undefined,
            enabled: item.enabled !== false,
        });
    }
    return tasks;
}
```

### config.json — 任务定义

```json
{
  "scheduledTasks": [
    {
      "id": "eda-weekly",
      "name": "xxx",
      "schedule": "3 8 * * 3",
      "platform": "feishu",
      "aiCommand": "codebuddy",
      "enabled": true,
      "prompt": "小智，按你的调研偏好生成xxx..."
    }
  ]
}
```

---

## 六、重新启动 & 手动验证

确认代码没问题后，重新启动服务：

```bash
systemctl start open-im
sleep 3 && grep -i "schedul" /root/.open-im/logs/restart.log | tail -5
```

输出：

```
[Scheduler] Task eda-weekly ("xxx") scheduled: 3 8 * * 3 on feishu
```

`systemctl status open-im` 确认 `active (running)`。

### 手动触发验证

之前写了一个 `trigger.js` 用于手动触发单次任务，但运行时发现 import 路径错误：

```
Error: Cannot find module '/root/.../open-im/dist/dist/config.js'
```

原因是 `trigger.js` 位于 `dist/scheduled-tasks/` 目录下，但 import 写的是 `from '../dist/config.js'`，路径多了一层。修复：

```bash
sed -i "s|from '../dist/config.js'|from '../config.js'|g" dist/scheduled-tasks/trigger.js
sed -i "s|from '../dist/session/|from '../session/|g" dist/scheduled-tasks/trigger.js
sed -i "s|from '../dist/feishu/|from '../feishu/|g" dist/scheduled-tasks/trigger.js
# ... 其他路径同理
```

修复后执行：

```bash
node dist/scheduled-tasks/trigger.js
```

完整链路跑通：

```
[TriggerScript] Triggering task: eda-weekly on feishu
[TaskRunner] [task=eda-weekly] Firing: platform=feishu, ...
[PlatformAI] [feishu] Running codebuddy for user scheduled:eda-weekly
[CodeBuddyCli] Spawning CodeBuddy CLI: path=codebuddy, ...
[AITask] SessionId callback: new=xxxxx
[TaskRunner] [task=eda-weekly] Completed successfully
[TriggerScript] Task result: SUCCESS
```

耗时约 1 分 44 秒，飞书成功收到 AI 生成的 EDA 行业简报。

---

## 七、排查方法论总结

这次排查的收获不仅仅是修好了一个问题，更重要的是总结了一套可复用的排查流程：

| 步骤 | 动作 | 本次关键发现 |
|------|------|-------------|
| 1. 看症状 | `systemctl status` + `journalctl` | 3 轮 restart 后被 systemd 保护停掉 |
| 2. 确认环境 | `npm list -g`、systemd service 文件 | nvm 路径，日志已配置 append |
| 3. 读日志 | `tail -100 restart.log` | Scheduler 日志出现，无 crash 堆栈 |
| 4. 验证代码 | 检查每个改动文件的 diff | 所有改动完整，依赖已安装 |
| 5. 手动运行 | 前台启动 + trigger 脚本 | 代码正常，trigger.js 路径 bug 修复 |
| 6. 确认恢复 | `systemctl start` + 日志验证 | 任务注册成功，手动触发验证通过 |

**核心教训：**

1. **日志是排障的第一优先级**。如果上来就猜测代码哪里写错了，很容易走弯路。先看日志，日志会告诉你真相。
2. **"一直重启"不等于"代码 crash"**。systemd 的 `Restart=always` + `StartLimitBurst` 会让"手动 stop"看起来像"崩溃重启"。
3. **改动黑盒代码（npm 包的 dist/）时，改动量要尽量小**。这次只改了两个文件（index.js + config.js），新增一个目录，改动边界清晰，排查起来也容易。
4. **写一个独立的触发脚本（trigger.js）是值得的**。它能绕过 systemd，直接在终端看到完整输出，排查效率远高于反复 `systemctl restart` + `journalctl`。

---

## 八、后续维护

### 添加新任务

编辑 `/root/.open-im/config.json`，在 `scheduledTasks` 数组中追加即可：

```json
{
  "id": "xxxx-weekly",
  "name": "xxx",
  "schedule": "0 9 * * 1",
  "platform": "feishu",
  "enabled": true,
  "prompt": "生成xxx..."
}
```

然后 `systemctl restart open-im`。

### 防止 npm update 覆盖

```bash
mkdir -p /root/.open-im/custom-patches
cp /root/.nvm/.../open-im/dist/index.js /root/.open-im/custom-patches/
cp /root/.nvm/.../open-im/dist/config.js /root/.open-im/custom-patches/
cp -r /root/.nvm/.../open-im/dist/scheduled-tasks /root/.open-im/custom-patches/
```

### 更根本的解决方式

给 [open-im](https://github.com/wu529778790/open-im) 提 PR，把 scheduled tasks 功能合进主仓库，这样就不需要维护 patch 了。

---

## 附：Cron 表达式速查

| 场景 | 表达式 | 说明 |
|------|--------|------|
| 每周三 8:03 | `3 8 * * 3` | 分 时 日 月 星期(0=周日) |
| 每周一 9:00 | `0 9 * * 1` | |
| 每天早上 8:00 | `0 8 * * *` | |
| 每月 1 号 10:00 | `0 10 1 * *` | |
| 每小时第 30 分 | `30 * * * *` | |

---

*本文记录了在腾讯云 Lighthouse 上为 Open-IM 添加 node-cron 定时任务的完整排查过程。从 systemd 日志分析到代码验证、手动触发、路径修复，最终成功实现了每周三自动推送 xxx的定时任务。*


前一阵子把 CodeBuddy CLI + Open-IM 部署到了腾讯云 Lighthouse 服务器上，实现了飞书消息 → CodeBuddy AI 的桥接。最近想让它支持定时任务，自动在每周三早上推送 xxx 定时任务。

Open-IM 定时任务"一直重启"？一次系统化排查实录

人工智能

本文详细记录了在腾讯云Lighthouse服务器上为Open-IM添加node-cron定时任务时遇到的systemd服务反复重启问题。通过分析日志、验证代码、修复路径错误等步骤，最终成功实现每周三自动推送消息功能，并总结了一套可复用的排查流程和方法论。

日志分析

代码解释

服务器

4核4G3M云服务器 新用户低至38元/年！

lighthouse

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Open-IM 定时任务"一直重启"？一次系统化排查实录-腾讯云开发者社区-腾讯云

Open-IM 定时任务"一直重启"？一次系统化排查实录

Open-IM 定时任务"一直重启"？一次系统化排查实录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐