logcheck.ignore文件用于白名单式忽略日志中无风险的常规条目，每行写一个大小写敏感的固定子串，不支持正则，仅做简单包含匹配；需避免过宽匹配，且须确保文件权限为644、属主root。
logcheck.ignore 文件的作用和写入规则
Logcheck 默认会把所有匹配 logcheck.hacking 或 logcheck.violations 的日志行当作异常上报，但很多“警告”只是系统常规行为，比如 postfix 队列轮询、systemd 单元重载、chronyd 时间偏移微调。这类信息不构成安全风险，却挤占报告体积。真正起过滤作用的是 logcheck.ignore —— 它不是黑名单，而是“白名单式忽略”：只要某行日志包含该文件中任意一行的子串，就跳过不报。
写入时注意三点：
- 每行只写一个关键字或短语，不要带空格或正则（Logcheck 不解析正则，只做简单子串匹配）
- 区分大小写，例如
avahi-daemon不会忽略Avahi-daemon - 避免过宽匹配，比如写
error会误杀真实错误；应写avahi-daemon\[.*\]: error这类带上下文的片段（但注意：方括号需转义为\[和\]才能生效）
如何验证 ignore 规则是否生效
Logcheck 不提供实时调试模式，必须靠手动模拟其处理流程来确认。核心是复现 logcheck.sh 中的过滤逻辑：
- 先用
logtail提取最新日志段（如logtail /var/log/syslog），保存为临时文件 - 用
grep -v -f /etc/logcheck/logcheck.ignore对该文件做反向过滤 - 再用
grep -E -f /etc/logcheck/logcheck.violations看剩余内容里是否还有你试图屏蔽的条目
如果第二步后某行仍出现在第三步结果中，说明 logcheck.ignore 里的关键字没覆盖到它的实际文本格式——常见原因是日志里含 PID、时间戳或路径变量，得把固定部分抠出来再试，比如把 sshd\[12345\]: 缩成 sshd\[ 或 sshd:。
哪些系统警告适合加进 logcheck.ignore
以下类型在多数生产环境可安全忽略，但需结合自身服务栈判断：
-
systemd\[.*\]: Started|Starting|Stopping（单元状态变更，非失败） -
chronyd\[.*\]: Source .* selected（NTP 源切换，属正常同步行为） -
avahi-daemon\[.*\]: Leaving mDNS multicast group（服务启停伴随的清理动作） -
kernel:.*: renamed from.*（网卡重命名，如 eth0 → ens33，仅首次出现） -
rsyslogd:.*: imjournal: journal files changed（journal 日志轮转触发）
注意：logcheck.ignore 不影响 logcheck.hacking 的匹配——如果某行同时命中 hacking 和 ignore，仍会被忽略；但若它只命中 violations 且不在 ignore 中，就会出现在报告里。
忽略规则失效的典型原因
最常踩的坑不是规则写错，而是 Logcheck 运行机制导致的“看似失效”：
-
logtail记录位置偏移：Logcheck 依赖/var/lib/logcheck/logcheck.logtail记录上次读取位置。如果手动清空过日志（如truncate -s 0 /var/log/syslog），logtail可能从头重读，导致大量旧 ignore 条目被重复上报 - 日志格式变化：升级 rsyslog 或 systemd 后，
journalctl -o short-iso输出格式可能变动，原先匹配systemd\[.*\]的规则对新格式的systemd\[.*\]:（末尾多冒号）就失效了 - 忽略文件权限错误：
/etc/logcheck/logcheck.ignore必须由 root 拥有且权限为644，否则 Logcheck 启动时静默跳过该文件
真正难处理的是那些动态生成的警告，比如内核模块加载日志里带随机地址或哈希值。这种没法靠子串忽略，得改用 logcheck.violations.ignore 配合更宽松的匹配逻辑——但那是另一个层级的配置了。
