📚 读书系统

探测 https://127.0.0.1:5001/api/health

首次 2026-10-04 22:29:01 / 末次 2026-10-05 09:14:58；样例：[N] [CRITICAL] WORKER TIMEOUT (pid:N) x33

探测 http://127.0.0.1:5910/health

整台 3.7GB 机器被单个 Python 进程压死。TCP 端口仍能 3ms 建连但协议层零响应：SSH 连上 20s 收不到 banner，HTTP curl 全部 20s 超时无响应码。gunicorn 已报 WO

api_bulk_enabled 原先只判登录，任何租客 POST 一次就能 UPDATE 全表 48 个账号。当时靠一张不存在的表意外挡住（INSERT 报错回滚）。

首次 2026-10-04 22:29:28 / 末次 2026-10-05 09:14:59；样例：[N] [ERROR] Worker (pid:N) was sent SIGKILL! Perhaps out of

首次 ? / 末次 ?；样例：Traceback (most recent call last): x5

样例：/.env | /.docker/.env | /.docker/laravel/app/.env

样例：/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php | /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php | /ve

样例：/.env.local | /.aws/credentials | /.aws/credentials.bak

样例：/.git/config | /.git/logs/HEAD | /.git/logs/refs/heads/main

样例：/wp-admin/install.php | /wp-content/plugins/hellopress/wp_filemanager.php | /wp-content/upgrade/wp-firewall

L30 NOW_STR = datetime.now().strftime('%Y-%m-%d %H:%M:%S')；L31 TODAY = date.today()

attendance.py:L839 <form method="POST" action="/apps/attendance/api/bulk_enabled" style="display:inline-block；

首次 2026-10-05 09:35:04 / 末次 2026-10-05 09:35:57；样例：ERROR in app: Exception on PATH [GET] x3

首次 ? / 末次 ?；样例：Traceback (most recent call last): x3

涉及表：people_ai_mistakes, people_finance, people_redlines, people_softspots, people_trust

修考勤算法的脚本未做内存上限，跑飞后持续占用 2GB。它不属于本会话，按纪律没有 kill，但它是宕机的直接原因。

access log 里有成规模的目录/配置文件探测，明显是自动化扫描器在找可下载的密钥与备份。需确认这些路径都不可访问，并在 nginx 层加规则拦掉。

原 blueprints/calendar.py 在 507 行被截断，api_create_event 无 INSERT 无 return 必 500；前端调的 PUT /api/calendar/events/<id

服务器 crontab 里根本没有日历条目。飞书同步 366 条事件 feishu_event_id 全 NULL，48 个用户 feishu_open_id 全空。

样例：/config.php | //cgi-bin/index.php | //cgi-bin/admin.php

样例：/database.sql | /db.sql | /backup.sql

疑似历史迭代遗留；空表过多会拖慢备份与迁移

huifu_merchant.py:L37 # POST https://api.huifu.com/v2/merchant/url/forward → HTTP 500（端点可达，参数校验问题）；huifu_m

运维手册/记忆里的路径与真实启动命令不符，照手册排障会扑空

运维手册/记忆里的路径与真实启动命令不符，照手册排障会扑空

疑似历史迭代遗留；空表过多会拖慢备份与迁移

疑似历史迭代遗留；空表过多会拖慢备份与迁移

无错误日志 = 出事无法定位；也可能是日志被 logrotate 移走

locks.py 的 api_list 按 owner_landlord_id 过滤可见性，但 api_unlock 只按 user_id。生产唯一那把锁 owner_landlord_id=NULL → 列表里看不见，

这 29 张表没有任何归属列，任何登录用户（含 32 个租客账号）都能查看全量档案。涉及对具体人的私密判断，敏感度最高。

模块级求值 once，gunicorn worker import 那一刻就永久冻结，16 处下游依赖它。

多 worker / 多房东并发会互相覆盖 token → 用错账号开门。

退款链路恒抛异常。修好路径后还会因 refund_amt vs trans_amt 退 0 元。

记忆记录应为 /var/log/landlord_saas_*.log，但实际 ps 显示又回到了 /tmp/。是别的会话重启时改的。启动命令与文档不一致，下次照文档操作会踩空。

conftest 修好后红测从 60 降到 45，零新增失败。剩下 45 个是「跑起来了但 fixture 没建全 schema」，属于要重写测试的活，不是回退。

app.py 是 Flask dev server 跑着 37 人真实档案。开发服务器不适合生产。

两项正常。zhaofang unit 在 /etc/systemd/system/zhaofang.service，环境变量 /etc/zhaofang.env，Restart=always。别再手工 nohup。