先说说我遇到这个问题时的第一反应Ubuntu机器跑着跑着突然开始不对劲apt upgrade报错说空间不足SSH会话打开半天才出提示符甚至某个服务直接起不来。df -h一看根分区那一行直接飘红到100%再往下一找/var/log/syslog、/var/log/kern.log这几个文件动辄几十GB进程列表里rsyslogd的CPU占用排在第一位。听起来像中毒实际上不是。rsyslogd是系统自带的日志守护进程它干的事就是把内核、服务、各种应用打出来的日志消息收集起来写进/var/log下面的文本文件。它不会自己制造日志也不会无缘无故膨胀——真正的原因通常是某些服务在疯狂刷日志、日志轮转失效、journal日志和文本日志两头同时吃空间。这篇就把我从排查到根治的完整路径捋一遍包括那些我踩过的坑以及怎么避免再次被磁盘写满。1. 先搞明白rsyslogd为什么会把根目录吃满1.1 rsyslogd和journald之间的关系很多刚接触Ubuntu的人会有一个疑问系统里明明有systemd-journald在收集日志为什么还要一个rsyslogd这不是重复劳动吗实际分工是这样的journald负责把内核和各服务的日志统一收到二进制日志里存到/var/log/journal目录如果配置了持久化或者只存在内存里而rsyslogd则是在这个基础上把日志消息以文本形式写到熟悉的/var/log/syslog、/var/log/kern.log、/var/log/auth.log等文件里。两者共存互为补充。问题恰恰出在这里一条日志消息会同时占用journald的二进制日志空间和rsyslogd写出来的文本日志空间。如果根分区本身分得就不大比如双系统安装时只给了30GB、虚拟机默认20GB那种两边各吃几个GB再叠加系统更新缓存、/var/cache/apt里的deb包根分区很快就满了。所以看到rsyslogd占空间别急着怪它。它只是那个执行者真正需要审视的是两个方向写入到/var/log/*.log的日志量以及journald持久化目录的体积。1.2 日志膨胀最常见的四类原因根据我处理过的案例根目录被日志写满基本上跑不出这四种场景第一种是日志轮转失效。Ubuntu默认通过logrotate来管理日志文件的轮转按天轮转、最多保留几个备份。但默认配置里没有按日志文件大小做限制日志量大的日子里一天能写好几个GB轮转到第二天时文件已经大得吓人了。更麻烦的是有些机器上logrotate因为配置权限问题静默失败从来没真正转过。第二种是某些服务在疯狂刷日志。最常见的是NetworkManager反复重连、libvirt的虚拟机日志刷屏、systemd本身反复上报某个错误、内核模块报错udev、usb设备反复插拔等。这些日志通常表现为syslog或者kern.log在极短时间内暴涨几百MB到几GB可能就是几个小时的事。第三种是journald没有做容量限制。journald默认允许日志占用磁盘的10%如果根分区是50GB它就能写到5GB如果根分区只有20GB2GB也是不小的负担。而且journalctl查起来特别方便很多人习惯用它查日志却从没想过给它画一条容量红线。第四种是磁盘快满时出现连锁反应。文件系统接近100%时rsyslogd写日志会出错出错还可能继续尝试写一些服务因为磁盘错误反复重启重启又是一轮日志输出雪球越滚越大。提示还有一种隐蔽情况就是日志文件被rm掉但进程还持有句柄。rsyslogd正打开着的文件被删除后空间并不会释放你df -h照样看到满但ls -lh /var/log/看到文件已经没了。排查时lsof | grep deleted能发现这类问题。2. 从上到下的完整排查链路从df到日志内容2.1 第一步确认空间大头在哪一层先把根目录空间使用情况看清按层级定位。df -h /这条命令先确认根分区整体使用率。如果显示/dev/sda2之类的设备挂载在/使用率98%那思路就明确是根分区内部的问题。然后逐层往下钻du -x -h --max-depth1 / 2/dev/null | sort -rh | head -20这里有个细节必须注意-x参数表示不跨文件系统。如果某些目录是独立挂载点比如你把/home或/var单独分区了不加-x会把它们也统计进来误判大头在系统目录里。通常在输出里会看到/var排在前面接着继续钻du -x -h --max-depth1 /var/log 2/dev/null | sort -rh | head -20到了这一层基本就能认出谁是元凶了/var/log/syslog、/var/log/kern.log、/var/log/journal是三个最常见的大户。顺便看下具体文件大小ls -lh /var/log/syslog /var/log/kern.log /var/log/journal如果syslog已经好几个GB那基本可以断定是文本日志轮转失灵加上某些服务刷日志如果journal目录特别大则是journald趁早没设上限。2.2 第二步检查logrotate是不是真的在干活logrotate的设计初衷是防止日志无限膨胀但它的执行可能因为各种原因失效而且经常是静默失效。先看当前的日志轮转配置cat /etc/logrotate.d/rsyslogUbuntu上这个文件默认内容大概是/var/log/syslog { rotate 7 daily missingok notifempty delaycompress compress postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }这里有个大坑默认配置只有daily按天轮转没有size按大小轮转。日志量不大的机器每天轮转没问题但日志量大的机器一天能写好几个GB等到第二天轮转时文件已经是个庞然大物了。而且大多数人的根分区被写满往往就是在这“一天”之内发生的。检查logrotate实际执行情况可以用调试模式强制试探logrotate -d /etc/logrotate.d/rsyslog-d是debug模式不实际执行只打印将要做什么。再加上-v就是详细模式logrotate -vf /etc/logrotate.d/rsyslog注意-v会真的执行轮转。如果配置有问题这里会直接报错比如权限不足、目录不存在、su配置无效等。一个很经典的坑是日志文件的owner变成了root而rsyslogd以syslog用户运行导致轮转后rsyslogd无法继续写入新文件进而日志膨胀。2.3 第三步查journal到底吃了多少空间journald的占用也很直接journalctl --disk-usage它会输出类似Archived and active journals take up 1.8G on disk.接着用journalctl看看有没有什么服务在狂刷。一条比较实用的组合journalctl --no-pager -o short | awk {print $5} | sort | uniq -c | sort -rn | head这条命令把journal里最近的消息按来源程序统计找出刷量最多的那个进程名。如果某个程序一秒刷几十条它就是你日志爆炸的源头。注意Journald在Ubuntu上如果没主动启用持久化日志默认只存在/var/run/log/journal内存文件系统重启即消失。只有/var/log/journal目录存在时journald才会持久化。所以如果你du -x -h /var/log看到journal占用很大说明这台机器是启用了持久化的。3. 动手救从应急清理到长效配置3.1 应急处理先把空间腾出来保住系统磁盘满的情况下系统随时可能进入异常状态。优先做的是释放空间而不是精细排查。但这步有个很多人都会犯的错——直接rm日志文件。千万不要直接rm /var/log/syslog。理由前面提过rsyslogd保持着一个打开的文件句柄你删掉文件后句柄还在空间不会被释放同时rsyslogd继续向这个已删除的inode写入甚至可能一直写、一直占着磁盘直到彻底无法写入。正确做法是清空文件内容truncate -s 0 /var/log/syslog truncate -s 0 /var/log/kern.log truncate -s 0 /var/log/auth.log这几个文件是常见的几个但具体机器可能还有别的日志文件比如/var/log/daemon.log、/var/log/syslog.1这类轮转后的旧文件。可以用通配的方式处理但有风险误伤还在写入的日志稳妥起见还是逐个确认后清理。清掉文本日志后顺便把journal也收一收journalctl --vacuum-size200M这条命令会立刻把journal压缩到不超过200MB是应急状态下的保底操作。这时候再回头看df -h /空间应该已经释放出一部分了。这时候去apt upgrade、重启服务都是安全的。提示truncate -s 0只是让文件现有内容清空文件本身还在。如果rsyslogd没有感知到文件被截断它可能继续从原有偏移量写入导致新日志头部出现空洞NUL字节。一般不影响系统功能但比较脏。安全起见清空后顺手重启一下rsyslogsystemctl restart rsyslog。3.2 给journald设好硬性容量上限临时清理只是第一步接下来要确保它不再无限膨胀。配置journald的地方是/etc/systemd/journald.confvim /etc/systemd/journald.conf需要关注和调整的参数[Journal] # 日志占用的最大磁盘空间 SystemMaxUse200M # 单个日志文件大小上限 SystemMaxFileSize50M # 日志保留时长超过自动删除 MaxRetentionSec2week # 写入同步策略fsync最安全但最慢默认也能接受 SyncIntervalSec5m解释一下SystemMaxUse是journald能用的最大磁盘量超过这个值会自动清理最旧的日志。像根分区只有20GB的双系统环境设成200M-500M是比较合适的范围既不担心占满也还能查最近几天的日志。SystemMaxFileSize控制单个journal文件的大小配合前面的上限避免一个文件无限增长。MaxRetentionSec是保留时间超过两周的日志直接丢弃。如果不需要历史审计可以设短一点。修改完配置后重启journaldsystemctl restart systemd-journald重启后可以把当前磁盘里的journal临时清一下让新配置立即生效journalctl --vacuum-size200M journalctl --vacuum-time7d这两条的区别是第一条按总量控制第二条按时间删除。实际使用中我喜欢先按时间砍掉超过两周的再按总量兜底。注意如果/var/log/journal目录不存在说明journald没有持久化上述配置只影响内存占用重启机器就会消失。如果希望日志重启后还在需要主动创建目录并授权install -d -o root -g systemd-journal -m 2755 /var/log/journal然后重启journald。3.3 修好logrotate按大小轮转才是治本方案journald只是其中一块更大的坑往往是文本日志文件。默认的daily轮转在日志量大的机器上形同虚设所以我的做法是给/etc/logrotate.d/rsyslog加上size限制。改造后的配置大致长这样/var/log/syslog /var/log/kern.log /var/log/auth.log /var/log/daemon.log /var/log/user.log { rotate 7 daily size 100M missingok notifempty delaycompress compress su root syslog postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }关键点说明size 100M单个日志文件超过100MB就轮转不再傻等一天。这是整个配置最重要的改动。rotate 7保留7个历史备份。备份会压缩通常占不了多少空间。delaycompress轮转后先不压缩当天的文件等下次轮转再压缩。好处是rsyslogd在新旧文件切换时不至于丢失日志坏处是当天会多一个未压缩的备份文件。su root syslog以root身份轮转、以syslog组身份写文件。不加这行如果日志文件owner不是运行rsyslog的用户轮转会失败。postrotate里的rsyslog-rotate脚本Ubuntu的rsyslog包自带这个脚本作用是向rsyslogd发送信号让它重新打开日志文件。如果用其他方式比如systemctl restart rsyslog重启瞬间的日志会丢而且重启期间新日志进不了文件。改完配置后手动验证一次logrotate -vf /etc/logrotate.d/rsyslog观察输出里每个文件是否正常轮转。确认无误后后续由cron daily自动执行。3.4 找到真正狂刷日志的元凶前面三步做完系统暂时稳定了。但如果不去找那个让日志暴涨的服务过几天可能又满了。定位元凶是我认为最需要耐心的一步。先看syslog尾部tail -n 200 /var/log/syslog刷日志有个特点不同来源的消息常常会有清晰前缀比如NetworkManager[1234]、systemd[1]、kernel:。看尾部几百行心里基本有数。如果交错太多可以统计一下最近一小时各类消息的占比方法核心思路是切割日志生成统计这一步只是为了快速聚焦到高频来源tail -n 20000 /var/log/syslog | awk {print $5} | sort | uniq -c | sort -rn | head$5是消息来源字段输出里最上面的那个就是刷量冠军。顺着它再定位如果是kernel:大量刷屏运行dmesg -T | tail -n 100看内核具体报什么错。可能是网卡驱动、USB设备、NVMe、ACPI之类的问题。比如我遇到过某块网卡反复报Link is down然后系统一次次尝试唤醒kern.log一天涨2GB。如果是systemd[1]刷屏大概率是某个服务反复重启systemctl status看有没有failed状态的服务。如果是NetworkManager看是不是Wi-Fi或移动宽带反复断开重连常见原因包括省电模式、信号不稳、DHCP超时等。如果是某个业务进程比如Java、PHP、数据库刷日志那是业务侧的问题回到应用配置里降日志级别或者修根因。处理原则是日志暴涨的背后一定有一条非正常的循环。只看日志本身而不解决循环logrotate和journald只是帮你把症状掩盖了。提示可以临时把日志级别调高来降低写入量比如NetworkManager的levelERR、systemd的LogLevelnotice、内核的printk级别等但这些都是缓冲手段。最终必须以找到循环根因为准。4. 实战速查与避坑清单三类高频场景的处置要点4.1 双系统/小分区场景空间不足的先天原因很多用户是在装双系统时给Ubuntu只分了20-30GB装完软件、缓存一多日志一下子就把剩余空间挤没了。这种场景下除了配置前面的journald和logrotate还要注意定期清理apt缓存sudo apt clean这条命令清空/var/cache/apt/archives下的deb包。在一台长期使用的机器上这部分缓存动辄1-2GB很值得清。根分区分得小的话建议从源头压缩日志留存周期journal保留一周、文本日志保留3个备份总占用控制在500M以内。日常日志查询走journal就够了文本日志更多是用于审计或rsyslog转发场景。4.2 容器日志和业务日志混在一起的情况用Docker跑业务时容器日志默认写到/var/lib/docker/containers/id/id-json.log不走rsyslog。如果你既开了journald持久化又用rsyslog转发容器日志同一份日志会被写两份根目录自然吃得快。对容器的日志量控制可以在/etc/docker/daemon.json配置{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }这样每个容器日志限制50MB、保留3个文件重启docker生效。业务容器铺得多的机器上这步比处理rsyslog还关键。4.3 内核反复报错刷满kern.log这类情况定位起来比较费劲因为内核日志一旦刷起来syslog和kern.log同步暴涨journal也一起沦陷。我遇到过一个典型案例某台老服务器网卡固件和Linux内核驱动配合出了问题网卡每过几分钟就断一次内核随之输出大量链路状态变更日志/var/log/kern.log一天半就写了4GB。当时的处置分三层临时truncate -s 0 /var/log/kern.log让系统先喘过气。中期journald设置SystemMaxUse100M避免journal跟着爆。根治更新网卡固件、换了一个内核参数modprobe驱动选项链路稳定后日志量立刻降回正常水平。这个例子说明日志膨胀是结果不是原因。只清日志不修问题等于给一个漏水的桶擦地板。5. 我踩过的坑和最后的经验整理几个值得专门说说的细节不要rm日志文件要用truncate。这个错误我早期也犯过。删掉/var/log/syslog后ls看着文件没了但df一点没变。后来才明白进程持有的是inode而不是文件名。rsyslogd对着已删除的文件继续写入系统甚至没法自动释放那块空间最后只能重启rsyslog才能回收。正确做法永远是用truncate -s 0清空内容保留文件。logrotate的静默失败最坑。配置文件里权限不对、owner不对它多数情况下不会正面报错只是不轮转。我就踩过/var/log/syslog的owner被某个脚本改成root后rsyslogd写不进去但文件也没轮转成功日志干脆堆在内存队列里最后rsyslog崩溃。排查这类问题靠logrotate -d调试输出一眼就能看穿。journald临时目录被掩盖的假象。一开始我发现journalctl --disk-usage只有几百MB觉得journal不是问题但/var/log还是爆了。后来才发现journald没启用持久化日志都在/run/log/journal内存盘没在/var/log统计里。所以手动建好/var/log/journal目录并授权让journald持久化到磁盘才能真正统一管理。回头看这个问题我的体感是日志不是系统制造出来的噪音它是系统写给你的报告。rsyslogd只是那个把报告递到你面前的邮差。把邮差当成罪魁祸首清完空间很快又会满真正要做的是读懂报告内容找到那个反复在喊“出事了”的服务。现在的做法是在每次新装Ubuntu后我直接把journald容量限制、logrotate的size轮转、apt缓存定时清理这三样加进初始化脚本里。之后机器跑得再久“根目录被日志写满”这个曾经三天两头上演的戏码基本没再出现过。