Linux 里和“资源不足回收”相关的日志，其实并没有一个统一的落点，排查时得按问题类型分别去看：内存 OOM 的记录，通常在 dmesg、journalctl -k 或 /var/log/messages 里；磁盘写满这类报错，往往分散在 journalctl -p 3、系统日志以及应用日志中；至于回收站操作，系统层面并不存在统一日志，只能结合 ~/.local/share/Trash/info/ 下的元数据做追溯。
Linux 没有统一的“资源不足回收日志”这个东西——内存、磁盘、inode 这三类资源不足触发的回收行为，日志来源、位置和格式完全不同，不能靠一个命令查全。得按具体资源类型分别排查。
内存不足触发 OOM Killer 的日志在哪
当物理内存彻底耗尽，内核会启动 OOM Killer 杀进程保系统，相关记录只写在内核环形缓冲区和系统日志里，不落回收站或用户目录。
dmesg是第一手来源：运行dmesg | grep -i "killed process"，能看到被杀进程名、PID、触发时的内存状态journalctl -k（systemd 系统）可翻更久远的内核日志，加--since "1 day ago"限定时间范围/var/log/messages或/var/log/syslog里也可能有重复记录，但依赖 rsyslog 配置是否捕获kern级别日志- 注意：
free -h显示可用内存低 ≠ 已触发 OOM；只有dmesg里出现Killed process才是真回收
磁盘空间满导致写失败的日志怎么看
磁盘写入失败不会自动“回收”，但应用/内核会报错，这些错误散落在不同地方，需结合现象定位。
- 先确认是不是真满了：
df -h看挂载点使用率，df -i看 inode 是否耗尽（常见于大量小日志文件） - 查最近报错：
journalctl -p 3 --since "2 hours ago"（-p 3 表示 err 级别），过滤出写入失败、no space left 等关键词 - 关键日志文件路径：
/var/log/messages、/var/log/syslog、/var/log/kern.log，用grep -i "no space" /var/log/messages快速扫描 - 某些服务（如 MySQL、Tomcat）会在自己的日志里直接写
Could not write to file: No space left on device，得去对应logs/目录翻
回收站操作本身有没有日志
Linux 桌面环境（GNOME/KDE）的回收站是用户级行为，不进系统日志；命令行工具 trash-cli 也不默认记日志，但可通过 info 文件间接追溯。
- 回收站元数据存于：
~/.local/share/Trash/info/下每个.trashinfo文件，用cat ~/.local/share/Trash/info/*.trashinfo可看到原始路径和删除时间 trash-list命令能列出当前回收站内容，但不显示删除时刻——它只是读取files/和info/目录的快照- 没有全局“谁在什么时候删了什么”的审计日志，除非你提前配置了 auditd 规则监控
rm或trash命令 history命令只能看到用户执行过trash put xxx或rm -rf，但无法区分是否进了回收站（rm是直删）
更棘手的，往往恰恰是那些几乎“不留字据”的回收动作。比如内核自动回收 page cache、swap 的换入换出，或者 logrotate 清理旧日志，这些过程通常不会直白地写上一句“资源已回收”，更多只是把结果零散地反映在各自的服务日志里。说白了，这类问题得顺着现象往回倒推，别指望在某个日志文件中直接翻到“Resource reclaimed”这样的明确提示。
