openclaw-sync/memory/2026-03-31.md

3.0 KiB
Raw Blame History

2026-03-31 Memory Flush

  • User asked to find the previously configured server health scheduled task and change it from hourly to four times daily at 00:00, 06:00, 12:00, and 18:00.
  • Investigation confirmed the active mechanism is not system crontab; current user crontab is empty and the effective scheduler is OpenClaw's built-in cron task.
  • Relevant reporting script exists at /home/sinlee/.openclaw/workspace/scripts/server-health-report.sh.
  • HEARTBEAT.md already reflected four scheduled times, but user wanted the real task verified.
  • Confirmed OpenClaw cron task ID 990700ff-be06-44c5-be10-19eaf3ed0af9 is already scheduled as 0 6,12,18,0 * * *, i.e. exactly 00:00 / 06:00 / 12:00 / 18:00 daily.
  • Task currently targets Telegram chat -1003834524994, topic 4.
  • Noted minor inconsistency: task display/name still says Server health report every 30m, but actual schedule is already the four-times-daily one.

2026-03-31 星期二 (Asia/Hong_Kong)

Telegram forum topic 群消息免艾特配置已验证可用

  • 用户已完成新版 OpenClaw Telegram 群/topic 配置调整。
  • 当前在 Telegram 群“龙虾指挥部” topic 4 中,机器人已经可以在不被 @ 提及的情况下正常回复。
  • 相关现有配置特征:
    • channels.telegram.groups.-1003834524994.requireMention = false
    • channels.telegram.groups.-1003834524994.topics.4.requireMention = false
    • channels.telegram.groupPolicy = allowlist
    • channels.telegram.groupAllowFrom 已包含用户 975333652
  • 说明新版 2026.3.23-2 下,群/topic 的免艾特响应链路已经打通。

Telegram 图片接收失败根因已定位

  • 用户反馈机器人“收不到图片”。
  • 排查日志后确认:不是 Telegram 消息没到,而是 OpenClaw 在下载 Telegram 图片文件时被 URL fetch 安全策略拦截
  • 关键现象:日志中出现类似
    • blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot... reason=Blocked: resolves to private/internal/special-use IP address
  • 当前判断:
    • 文字链路正常;
    • 媒体链路在下载 api.telegram.org/file/... 时被安全检查阻断;
    • 高概率与宿主机 DNS/hosts/代理解析结果,或当前版本 URL 安全判定过严有关。
  • 用户明确希望走“方案 2”通过 OpenClaw 配置放行/修复),后续应继续根据本地新版文档核对是否存在正式支持的 URL fetch 放行键名,再决定是否修改配置。

夜间风扇变快排查结论

  • 2026-03-31 凌晨用户反馈主机风扇转速明显加快。
  • 排查结果:OpenClaw 本身不是主因
  • 当时资源占用最高的进程:
    • ffmpegJellyfin 转码路径)约 101% CPU
    • baidunetdisk21% CPU
    • qemu-system-x86_647% CPU
    • OpenClaw 自身约 0.4% CPU
  • 系统整体负载并未爆满:
    • load average1.59 / 1.47 / 1.76
    • 主机有 16 CPU
    • CPU 平均空闲仍约 89.91%
  • 结论:更像是 Jellyfin 正在进行实时转码/媒体处理,带动风扇升速,而不是整机高压或 OpenClaw 失控。