rsyslog服务未启动导致日志链路中断，需先验证进程状态（systemctl status rsyslog、ps aux | grep rsyslogd），再检查配置语法（rsyslogd -N1）、启动错误（journalctl -u rsyslog -n 30 -b）、Unix Socket通路（/dev/log权限与imuxsock模块）、权限及SELinux干扰。
rsyslog 服务没起来，日志就断了——这不是“没记录”，而是整条日志链路的第一环卡住了。排查重点不是翻旧日志（它根本没存），而是验证 rsyslog 是否真在运行、是否能收日志、配置有没有拦住它。
确认 rsyslog 进程是否存活
先看最基础的状态：
- 运行 systemctl status rsyslog，检查是否为 active (running)；若显示 failed 或 inactive，说明服务根本没跑起来
- 执行 ps aux | grep rsyslogd，确认是否有
rsyslogd进程在运行；没有进程，基本可判定服务未启动或启动失败 - 注意：有些系统默认禁用 rsyslog（如部分 minimal CentOS/AlmaLinux 镜像），需手动启用：systemctl enable --now rsyslog
检查启动失败的直接原因
服务起不来，通常卡在配置或依赖环节：
- 用 rsyslogd -N1 -f /etc/rsyslog.conf 校验主配置语法；报错会明确指出哪一行有缺失分号、错别字或非法参数
- 如果用了
include引入其他文件（如/etc/rsyslog.d/*.conf），对每个被包含文件也执行 rsyslogd -N1 -f 文件路径 - 查看启动时的原始错误：journalctl -u rsyslog -n 30 -b（-b 表示本次 boot 的日志），找 ERROR 或 Failed to load module 类提示
验证日志接收通路是否畅通
即使进程在，也可能收不到日志——常见于 Unix Socket 断连：
- 检查 /dev/log 是否存在且权限正确：ls -l /dev/log 应显示
srw-rw-rw-，属主 root；若不存在，重启 systemd-journald（它负责创建该 socket） - 确认
imuxsock模块已加载：在/etc/rsyslog.conf或/etc/rsyslog.d/*.conf中查找module(load="imuxsock")；没这行就加进去再重启 - 手动发一条测试日志：logger "rsyslog-test"，然后立刻执行 tail -n 5 /var/log/messages；没看到这条，说明日志从源头就没进 rsyslog
排除权限与 SELinux 干扰
尤其在 RHEL/CentOS 系统上，这两项常静默拦截：
- 检查 rsyslog 写入目标目录的权限，例如
/var/log/messages所在目录：ls -ld /var/log，确保 rsyslog 用户（通常是syslog或root）有写权限 - 临时关闭 SELinux 测试：setenforce 0，再重启 rsyslog；若日志恢复，说明 SELinux 策略限制了写入，需用 audit2why 分析日志并生成策略
- 检查 rsyslog 的 SELinux 上下文：ls -Z /usr/sbin/rsyslogd 和 ls -Z /var/log/，应匹配
system_r:syslogd_t和system_u:object_r:var_log_t
