1. 问题现象日志中的Started Session风暴最近在维护一台CentOS服务器时发现/var/log/messages里每分钟都会新增这样的记录Jun 23 09:00:01 server1 systemd: Started Session 775 of user root. Jun 23 09:00:01 server1 systemd: Starting Session 775 of user root. Jun 23 09:01:01 server1 systemd: Started Session 776 of user root.这些日志虽然不会导致系统故障但会带来三个实际问题首先它们会快速填满日志文件增加磁盘空间压力其次大量无关日志会干扰真正重要信息的查找最后频繁的日志写入还可能影响磁盘I/O性能。特别是在使用日志分析工具时这些重复条目会导致有效信息被淹没。通过观察可以发现两个规律一是时间间隔非常固定示例中是每分钟二是都关联到root用户的会话。这种规律性往往意味着背后有定时任务在驱动。我曾经处理过一台服务器仅一周这些日志就占用了2GB空间导致关键的OOM错误日志被自动轮转删除。2. 根源分析systemd的会话管理机制要理解这些日志的来源需要先了解systemd的会话管理方式。当用户通过SSH登录或执行特权命令时systemd-logind会创建临时会话session每个会话都有唯一ID。这种设计原本是为了实现多用户环境下的资源隔离比如通过cgroups限制每个会话的资源使用。但在实际运维中我们发现两种典型场景会触发大量会话记录一是系统级cron任务二是某些后台服务定期执行的管理操作。比如sysstat工具包的sa1命令就会每分钟收集系统性能数据每次执行都会创建新会话。这就像办公室里的打卡机每次有人进出都会产生记录即使进出的是同一个人。通过以下命令可以查看当前活跃会话loginctl list-sessions输出示例SESSION UID USER SEAT TTY 1 0 root pts/03. 排查实战定位问题源头3.1 检查定时任务首先检查root用户的crontabcrontab -l如果没有发现可疑任务接着检查系统级定时任务目录ls -l /etc/cron.d/在我遇到的一个案例中/etc/cron.d/sysstat文件包含这样的配置# Run system activity accounting tool every 10 minutes */10 * * * * root /usr/lib64/sa/sa1 1 1这正好匹配日志中出现的时间规律。可以通过以下命令验证任务执行时间grep systemd: Started Session /var/log/messages | awk {print $3} | uniq -c3.2 追踪进程调用链如果定时任务没有发现问题可以使用systemd-cgls查看调用关系systemd-cgls --all | grep session或者通过进程树定位pstree -p | grep -A 5 systemd-logind4. 解决方案四种根治方法4.1 方法一调整日志过滤规则推荐创建rsyslog过滤规则文件cat /etc/rsyslog.d/ignore-systemd-session.conf EOF if $programname systemd and ($msg contains Starting Session or $msg contains Started Session) then stop EOF然后重启服务systemctl restart rsyslog这种方法的优点是只影响日志记录不会改变系统行为。我在生产环境中更推荐这种方式因为它既解决了日志干扰问题又保留了系统原始的运行状态。4.2 方法二修改systemd日志级别编辑systemd配置文件vim /etc/systemd/system.conf找到并修改LogLevelnotice然后重新加载配置systemctl daemon-reload注意这会全局降低systemd的日志详细程度可能隐藏其他重要信息。建议在修改后密切监控系统状态。4.3 方法三禁用特定定时任务如果确认是某个cron任务导致的问题可以直接注释掉相关行。例如针对sysstatsed -i s/^\(.*sa1\)/#\1/ /etc/cron.d/sysstat但要注意这会影响相关功能的正常运行。在我的实践中曾遇到过禁用sa1后导致sar命令无法生成历史数据的案例。4.4 方法四调整systemd-logind配置对于频繁创建会话的服务可以修改logind配置vim /etc/systemd/logind.conf添加或修改NAutoVTs0 ReserveVT0然后重启服务systemctl restart systemd-logind5. 进阶技巧日志管理与分析5.1 使用journalctl高效查询systemd自带的日志工具可以精确过滤journalctl _SYSTEMD_UNITsystemd-logind.service --since 2024-06-01 --until 2024-06-02或者统计会话创建频率journalctl -u systemd-logind | grep New session | awk {print $1,$2,$3} | uniq -c5.2 配置日志轮转防止日志文件过大vim /etc/logrotate.d/syslog示例配置/var/log/messages { daily rotate 7 compress delaycompress missingok notifempty create 640 root adm }5.3 自动化监控脚本可以部署这样的shell脚本定期检查#!/bin/bash LOG_COUNT$(grep -c Started Session.*root /var/log/messages) if [ $LOG_COUNT -gt 100 ]; then echo Warning: Excessive root sessions detected | mail -s Session Alert adminexample.com fi6. 预防措施系统配置优化6.1 审计定时任务建议定期检查所有定时任务find /etc/cron* -type f -exec ls -la {} \; -exec cat {} \;6.2 最小化root使用改用普通用户sudo方式执行任务减少root会话visudo添加%ops ALL(ALL) NOPASSWD: /usr/lib64/sa/sa16.3 系统服务调优对于非交互式服务可以配置systemctl edit some-service.service添加[Service] TTYPath/dev/null StandardInputnull经过这些调整后最近检查的一台原本每分钟产生会话日志的服务器现在日志量减少了约70%关键错误信息的查找效率明显提升。记住处理系统日志问题就像医生看病——找到病因比简单止痛更重要。