ausearch --start recent -m avc -i 返回空是因recent依赖auditd日志周期而非时间，应改用--start加date或直接ausearch -m avc -i；AVC denied未必影响业务，需结合sealert分析；-i失效常因policycoreutils-python-utils未安装或auditd未重启；大日志建议用journalctl _TRANSPORT=audit或tail缩小范围。
ausearch 查不到 recent 的 AVC 日志？
默认情况下 ausearch --start recent -m avc -i 很可能返回空，不是命令写错了，而是 recent 依赖系统时钟和 auditd 的日志轮转状态。它不表示“最近几条”，而是指 auditd 内部标记的“最近一个完整日志周期内”的事件——如果 auditd 刚启动、日志被清空或时间回拨过，recent 就会失效。
-
ausearch -m avc -i（不带--start）能查全部已加载进内存的日志，更可靠 - 想查过去 10 分钟的，用
ausearch -m avc -i --start $(date -d '10 minutes ago' '+%m/%d/%H:%M:%S') - 注意系统时区：audit 日志时间戳是本地时区，
date命令必须匹配，否则查不到
AVC denied 日志爆满，但实际服务没异常？
大量 AVC denied 不一定代表功能受损，可能是 SELinux 策略过于保守，或者应用行为触发了未授权的路径访问（比如 Python 进程读取 /proc/self/attr/current、Node.js 加载非标准路径的 .so）。关键看是否伴随进程崩溃、拒绝响应或明确的权限错误。
- 先确认是否真影响业务：
ausearch -m avc -i | grep -E "(denied|comm=)" | head -20看具体被拒的操作和主体 - 常见“无害”场景：容器运行时（如 podman）、IDE（如 VS Code Server）、语言运行时（如 Rust 的
std::env::current_dir()调用）频繁触发策略检查 - 不要直接关 SELinux（
setenforce 0），先用sealert -a /var/log/audit/audit.log解析语义，它比 raw AVC 更易读
ausearch -i 解析失败或字段为空？
-i 参数依赖 SELinux 策略包中预编译的翻译规则（policycoreutils-python-utils 提供），如果系统没装或版本不匹配，就会显示原始数字（如 scontext=u:r:unconfined_t:s0 无法转成 human-readable 名称），甚至报错 Failed to resolve type。
- 检查是否安装：
rpm -q policycoreutils-python-utils（RHEL/CentOS/Fedora）或dpkg -l selinux-utils（Debian/Ubuntu） - 策略更新后需重启 auditd：
systemctl restart auditd，否则-i仍用旧映射 - 解析卡住？加
--input /var/log/audit/audit.log显式指定路径，避免ausearch自动扫描所有归档导致超时
audit.log 太大导致 ausearch 慢或 OOM？
单个 audit.log 超过几百 MB 后，ausearch 加载和过滤会明显变慢，尤其带 -i 时内存占用翻倍。这不是 bug，是设计使然：它要把整块日志读入内存再逐行解析。
- 优先用
journalctl _TRANSPORT=audit替代——如果 auditd 配置了log_format = ENRICHED并启用了 journald 转发 - 定期轮转：
logrotate配置里确保auditd的日志有maxsize和rotate，别只靠max_log_file - 紧急排查时，先
tail -n 10000 /var/log/audit/audit.log | ausearch -m avc -i缩小范围，再逐步扩大
真正麻烦的是跨多个 audit.log.* 归档的长期追踪——ausearch 不自动合并，得手动拼接路径或改用 audispd 实时过滤。这点容易被忽略，等发现漏了三天前的日志才反应过来。
