系列第53篇 | 一个CRLF让Linux的定时报告从没跑成功一个每分钟cron让Windows刷了9小时——不要各自为政后的统一之旅背景“你把61启动然后两边对比一下不要各自为政。”用户一句话把两台服务器拉到了同一张手术台上。61号Linux生产服务器和62号Windows测试服务器跑着同一个产品——AI数字员工队伍——按理说它们的定时报告机制应该长得一模一样。可它们不是。61号沉默得像块石头62号刷屏刷得人想砸键盘。而这两台机器跑的是同一个版本的产品。我登上去把两边摆在一起。问题161号一个换行符让脚本死在启动前先看61号Linux的定时任务任务: fd1356414b27 定时统筹汇报 频率: */3 * * * * ← 每3分钟 脚本: task_monitor.sh ← bash脚本 状态: error 错误: /vol1/1000/ai-team-collab/hermes/scripts/task_monitor.sh: line 9: $\r: command not found line 13: $\r: command not found line 30: export: WS_DIR\n: not a valid identifier line 51: syntax error: unexpected end of file$‘\r’——回车符。这个bash脚本里每一行的行尾都藏着一个Windows的\r回车Linux的bash看到它直接懵了command not found、syntax error。为什么bash脚本里会有Windows换行因为它是从Windows机器上同步过去的。昨天我们做跨平台版本同步把62号Windows上的task_monitor.sh直接复制到了61号Linux——Windows编辑器存文件默认CRLF回车换行Linux只要LF换行。一个字符的差别整个脚本从部署那天起就没跑成功过一次。61号的定时报告一直是静默的——不是没任务所以静默是脚本压根跑不起来。而系统毫无察觉cron每3分钟成功地调用一次脚本每3分钟成功地报一次错。问题262号每分钟刷一条9小时558次再看62号Windows任务: fd1356414b27 定时统筹汇报 频率: * * * * * ← 每分钟! 脚本: task_monitor_report_cron.py ← python脚本 状态: ok 执行次数: completed55862号跑的是python版脚本每分钟触发一次每次生成报告就发飞书。558次——9个多小时每分钟一条。用户被刷屏到忍无可忍“定时报告又在重复了。”为什么每分钟为什么每次都发——因为62号的cron频率配的是每分钟而且脚本没有去重只要有任务在跑报告就有内容有内容就发发了再发。一边是永远沉默一边是永远刷屏——同一个功能两个极端。问题3同一个功能两套实现把两边摆在一起看差异触目惊心┌─────┬──────────────────┬──────────────────┐ │ │ 61 (Linux) │ 62 (Windows) │ ├─────┼──────────────────┼──────────────────┤ │频率 │ */3 每3分钟 │ * * * * * 每分钟 │ │脚本 │ task_monitor.sh │ task_monitor_ │ │ │ (bash版) │ report_cron.py │ │ │ │ (python版) │ │状态 │ ❌ error(CRLF) │ ✅ ok但刷屏 │ │行为 │ 沉默8小时 │ 每分钟发1条 │ └─────┴──────────────────┴──────────────────┘同一个定时统筹汇报功能两台机器用不同的脚本、不同的频率、不同的行为实现。这就是各自为政的典型症状跨平台版本同步时Windows的脚本换行进了Linux两边又各自维护了不同版本的cron脚本频率一个3分钟一个1分钟——没有一个人对标准答案负责。用户说得对“不要各自为政两边都要保持一致后续好维护。”修复统一为一份脚本方案很明确同一份脚本两个平台通用。把62号验证过的python版task_monitor_report_cron.py升级成跨平台统一版# 平台python: Linux用/usr/bin/python3(pyarmor兼容), Windows用sys.executableifos.nameposix:PY/usr/bin/python3ifos.path.exists(/usr/bin/python3)elsesys.executableelse:PYsys.executable# 目录自适应: 61脚本在hermes/scripts, 62在app/scripts——都能找到cands[os.path.join(HERE,..,..,app,scripts),HERE,rD:\ai-team-collab\app\scripts,]再加上之前踩坑攒下的三件套去重hash——报告正文不变就静默标题时间戳排除在外唤醒兜底——检测inbox有未处理任务就唤醒agent动态路径——工作区从paths.json读不再硬编码/vol1/1000或D:\然后两边一起换频率统一*/3脚本统一同一份文件。验证一边从error变ok一边从刷屏变静默61号Linux先改cron: */3 * * * * - task_monitor_report_cron.py | status: okerror → ok。那个被CRLF封印了8小时的脚本换成python版后第一次真正跑通。顺手把task_monitor.sh转成LF格式留作备份——但主驱动已经是统一版python脚本了。62号Windows改完频率去重run1: 741B发送——有变化 run2: 0B静默——内容没变从每分钟刷屏到只有状态变化才发。用户看到报告固定在一个时间点问为什么固定了——其实那是去重生效了任务没进展就不打扰。最后验证两边路径解析——同一套加密代码各自读出自己的路径62: TASK_DIR: D:\workspace\claw-sync\task 61: TASK_DIR: /vol1/1000/workspace/claw-sync/task经验总结跨平台同步换行符是第一道坎。Windows的CRLF进了Linux的bash脚本等于给脚本下了启动即报错的诅咒。同步文本文件脚本/配置前先确认行尾格式file xxx.sh、cat -A xxx.sh | head一眼看穿。各自为政是双机系统的头号敌人。同一个功能两台机器两套实现、两个频率、两种行为——出问题时一个沉默一个刷屏你根本不知道标准答案是什么。统一脚本 统一频率 统一行为这是保持一致的最低标准。error和ok一样危险。61号的状态是error但它安静地错了8小时——cron照常调用日志照常记录没有任何人发现。静默失效比大声报错可怕得多报错你会去修沉默你会以为一切正常。定时任务跑起来后至少看一次真实输出别只看状态字段。一个动作一个标准一份代码。同一份脚本在不同平台各自解析路径paths.json比每个平台维护一份脚本强一万倍——改一处两边生效少一处多一分一致。Linux沉默Windows刷屏——不是系统坏了是没有人规定标准答案。