From cb6b0b58a0759de6fb1d09b0510ba5bd3fa057d6 Mon Sep 17 00:00:00 2001
From: ATRI <atri@kronecker.cc>
Date: Mon, 14 Sep 2026 00:03:19 +0800
Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20=E8=87=AA=E5=8A=A8=E6=97=A5?=
 =?UTF-8?q?=E5=BF=97=EF=BC=9A2026-09-13=EF=BC=88questions=20=E5=BD=92?=
 =?UTF-8?q?=E6=A1=A3=EF=BC=9A=E9=80=9A=E9=81=93=E5=A4=B1=E6=95=88=E7=AC=AC?=
 =?UTF-8?q?5=E6=97=A5=20+=20SSH=20=E9=80=9A=E9=81=93=E6=92=91=E7=88=86?=
 =?UTF-8?q?=EF=BC=89?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../2026-09-11-历史记录查询工具通道失效.md    | 12 +++++
 .../2026-09-13-SSH通道被超长回显撑爆.md       | 45 +++++++++++++++++++
 2 files changed, 57 insertions(+)
 create mode 100644 ATRI My Dear Moments/questions/2026-09-13-SSH通道被超长回显撑爆.md

diff --git a/ATRI My Dear Moments/questions/2026-09-11-历史记录查询工具通道失效.md b/ATRI My Dear Moments/questions/2026-09-11-历史记录查询工具通道失效.md
index d3ca8ac..8798d0a 100644
--- a/ATRI My Dear Moments/questions/2026-09-11-历史记录查询工具通道失效.md	
+++ b/ATRI My Dear Moments/questions/2026-09-11-历史记录查询工具通道失效.md	
@@ -71,3 +71,15 @@ astrbot.db   → conversations 表 0 行 / platform_message_history 表 0 行
 建议排查优先级上调：先确认该插件到底读的是哪个文件 / 哪张表（`ls -l --time-style=long-iso` 看最后修改时间即可一眼分辨）。
 
 *记录：ATRI 🥕 · 2026-09-13 00:00 · 每日日志 CronJob 中第三次确认*
+
+---
+
+## 七、第 5 日补充（2026-09-13 晚间 · 9/14 00:00 日志任务）
+
+**症状不变，处置进入稳定态。**
+
+- 本日全天（含 12:00 / 18:00 / 00:00 三个场次）继续以**本地 JSONL 全量时间戳扫描**为唯一数据源，未再对该通道做任何调用尝试。
+- 结论维持：**永久弃用 + 以 JSONL 为准**，不建议再投入排查时间，除非主人希望恢复多端历史查询能力。
+- 补充一条**连带缺口**：本日 18:00 场次的「下午快照」任务**未落盘**（触发后无写入，12:00~17:59 整段一度缺失），已由 00:00 任务补录。两个问题是独立的——**这次不是数据源的问题，是任务本身没跑完**，后续若再复现需单独排查。
+
+*记录：ATRI 🥕 · 2026-09-14 00:00 · 每日日志 CronJob 中第五次确认*
diff --git a/ATRI My Dear Moments/questions/2026-09-13-SSH通道被超长回显撑爆.md b/ATRI My Dear Moments/questions/2026-09-13-SSH通道被超长回显撑爆.md
new file mode 100644
index 0000000..0af8aa1
--- /dev/null
+++ b/ATRI My Dear Moments/questions/2026-09-13-SSH通道被超长回显撑爆.md	
@@ -0,0 +1,45 @@
+# SSH 工具通道被「超长回显」撑爆后彻底失联
+
+**发现时间**：2026-09-13 12:52（下午快照时段）
+**当前状态**：🔴 未恢复（需重启 SSH 插件）
+**影响任务**：期货回测（一位群友的请求）、以及**所有依赖 `ssh_exec` 的运维类任务**
+
+---
+
+## 一、现象
+
+`ssh_exec` 在某次**返回内容极长**的命令之后，通道彻底失效，此后所有调用一律返回：
+
+```
+Channel not open for sending
+```
+
+- 不是脚本报错、不是权限问题、不是远端拒绝——**是本地这条连接本身没了**。
+- 时间线：12:52 首次失败 → 13:00 第二次 → 13:20 第三次 → 13:50 第五次，**五次重试、五次同样失败**，最后按约定停止重试、不再刷屏。
+
+## 二、触发条件推测
+
+- 出事前最后一条 `ssh_exec` 的**回显内容超长**（接近输出上限被截断）。
+- 推测：**输出量大到把这条长连接（或它的缓冲区）撑爆**，连接被单方面丢弃，而插件侧没有自动重连。
+- 反例佐证：**同一晚** 22:04 的另一台机器上，fail2ban 部署全程（十余条 `ssh_exec`）**完全正常**——所以问题不是「插件整体坏了」，而是**这条具体连接死了**。
+
+## 三、影响面
+
+- 🔴 期货回测**全部卡在最后一步**：数据已拉取（玉米 5275 根 / 玻璃 3338 根日线，至 9/11）、脚本已写好并自检修过一版（v0.3.1），**只差执行**。
+- 🟢 不影响 ATRI 的正常对话、日志、博客、邮件等通道。
+- 🟢 另一台机器的运维通道当晚实测正常。
+
+## 四、已做的处置
+
+- 停止重试（避免刷屏与雪上加霜），并**如实向请求方说明**：这是管道的问题，不是脚本的问题。
+- 未做任何重启动作——**等主人发话**。
+
+## 五、建议
+
+1. **重启 SSH 插件**（最直接，预计即可恢复）；重启后先 `echo ok` 验证再跑长任务。
+2. **根治**：给长输出类命令加**输出上限 / 分块读取 / 重定向到远端文件再分段取**的保护，避免单次回显再次撑爆通道。
+3. 可考虑给 `ssh_exec` 加**自动重连**。
+
+---
+
+*记录：ATRI 🥕 · 2026-09-14 00:00 · 每日日志 CronJob 中归档*