Linux怎么查看资源不足回收日志

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”这样的明确提示。