¶源起

突然准备写这么一个汇总，是因为今天在外卖发现连不上内网了，准确的说不是连不上，而是几个应用访问都是404，一开始我还以为是容器批量挂了，甚至宿主机崩了。回来后处理之后想着干脆写一个汇总吧，如果日后再遇到也有迹可循。

¶postgreSQL

2026年3月24日

晚上回来看了 authentik 日志，连不上数据库，下意识以为昨晚改配置挂了，然后

检查服务状态：

1 2	# 检查服务是否运行 sudo systemctl status postgresql

正常的

查看日志：

1 2	cd /var/log/postgresql tail -10f postgresql-18-main.log

定位到报错原因是磁盘满了无法写入wal日志：

2026-03-24 02:22:47.197 CST [1796481] 日志:  归档命令执行失败，退出代码为 1
2026-03-24 02:22:47.197 CST [1796481] 详细信息:  执行失败的归档命令是: test ! -f /data/backup/wal/000000010000000D000000F8 && cp pg_wal/000000010000000D000000F8 /data/backup/wal/000000010000000D000000F8
2026-03-24 02:22:47.197 CST [1796481] 警告:  归档预写日志文件 "000000010000000D000000F8" 多次失败, 将会重试
2026-03-24 02:22:47.657 CST [1796850] authentik@authentik 比致命错误还过分的错误:  无法写入文件 "pg_wal/xlogtemp.1796850": 设备上没有空间
2026-03-24 02:22:47.657 CST [1796850] authentik@authentik 语句:  DELETE FROM "django_postgres_cache_cacheentry" WHERE "cache_key" IN ('public::1:goauthentik.io/flows/planner/ecade04d-2b44-4b7f-9e63-76506539085b#None')
2026-03-24 02:22:47.658 CST [1692628] 日志:  client backend (PID 1796850) 被信号 6 中断: 已中止
2026-03-24 02:22:47.658 CST [1692628] 详细信息:  失败进程:DELETE FROM "django_postgres_cache_cacheentry" WHERE "cache_key" IN ('public::1:goauthentik.io/flows/planner/ecade04d-2b44-4b7f-9e63-76506539085b#None')正在运行
2026-03-24 02:22:47.658 CST [1692628] 日志:  中断任何其它已激活的服务器进程
2026-03-24 02:22:47.676 CST [1692628] 日志:  所有的服务器进程被中止; 重新初始化
2026-03-24 02:22:47.698 CST [1796854] 日志:  数据库系统中断；上一次的启动时间是在2026-03-24 02:22:01 CST
2026-03-24 02:22:47.700 CST [1796855] authentik@authentik 致命错误:  数据库系统在恢复模式中
2026-03-24 02:22:47.708 CST [1796858] authentik@authentik 致命错误:  数据库系统在恢复模式中
2026-03-24 02:22:47.835 CST [1796854] 日志:  数据库系统没有正确的关闭; 处于自动恢复状态中
2026-03-24 02:22:47.841 CST [1796854] 日志:  redo 在 E/100EA18 开始
2026-03-24 02:22:47.845 CST [1796854] 日志:  redo done at E/2088E48 system usage: CPU:用户：0.00 s，系统：0.00 s，已用时间：0.00 s
2026-03-24 02:22:47.853 CST [1796854] 致命错误:  无法写入文件 "pg_wal/xlogtemp.1796854": 设备上没有空间

紧急处置

删除 wal 目录重启数据库。

后续处置

配置定时任务每小时检查 wal 目录大小，限制在20G以内。

¶阿里云磁盘告警

2026年5月6日

¶事件起因

今天无意打开阿里云APP看看，就看到右上角慢慢十几封通知，想着应该全都是推广，一点开，怎么是告警？全都是磁盘超过75%告警，不过也才超过阈值0.几，倒也就没那么紧急，回家了再慢慢处理。

¶原因

首先怀疑是/home或者/data(docker主目录)，/var下docker镜像、数据太大了，但是实际 du 看完最大也才3个G，直接 du -sh /* 就看到 /var 不对劲，一层一层检查，原来是 /var/rdma/log 下日志问题。

顺便也发现居然还在写两年前的日志文件：

1 2	# lsof \| grep journal.log rstatd 21428 root 4u REG 253,3 12185295036 36263449 /var/rdma/log/journal.log-20241207

轮转没生效。

¶处置方案

强杀进程：kill -9 <PID>；
删除历史日志文件

修改轮转配置：

   /var/rdma/log/journal.log {
    size 100M
    rotate 7
    compress
    delaycompress
    copytruncate
    missingok
    notifempty
}

/var/rdma/log/err.log {
    size 100M
    rotate 7
    compress
    delaycompress
    copytruncate
    missingok
    notifempty
}

效果如何就要等后面再观察观察了。