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”这种行。
