记一次由Ubuntu系统日志引发的存储雪崩
Table of Contents
#
问题出现
事情是这样的，4.5号晚我在写没写完的三月总结，系统突然提示存储空间不足，很奇怪，明明之前还有七八十个G的。难道是中木马了？
然后紧急保存文章，但是因为0字节可用，文章直接消失了。md文件直接显示0字节。我悲痛万分，开始排查。
#
占用排查
因为好久没有登陆tg了，就这次登录出问题了，还以为是tg的聊天记录太多了，然后删除了好多，发现并没有什么用。
软件确实也没啥奇怪的，今晚还安装了tradingview但是连不上网就卸载了。
然后去检测磁盘的空间，使用dust这个CLI应用，算是du命令的升级版。还有看了一下Ubuntu系统自带的系统占用分析器。
最终锁定在/var/log/syslog这个文件，整整106G。
然后我把这个日志mv到了我的硬盘里，先让系统恢复正常，准备去分析。
#
恢复typora内容
写了这么久的博客突然消失，挺难过的。还在想重写一遍又得花大量时间，去网上搜了搜typora的崩溃恢复。
还真找到了！https://blog.csdn.net/m0_51360693/article/details/120458414
在偏好设置里有个恢复为保存的草稿。
太好了！！内容都在，typora这会员没有白买！！！
遇到问题一定要保持冷静，尽力去想办法恢复，不要自暴自弃。
文档损坏的时候，我整个人都陷入低迷状态，很无力，还好我抱着试一试的心态去找解决方案而不是摆烂。
不要被情绪控制。
#
日志分析
刚才是给大文件挪出来了，需要具体分析，但是文件太大了，没法直接预览。
用grep命令正则匹配某天的日志输出再查看。
grep -E '^2025-04-05' ../syslog > 04-05.log 发现重定向的文件很大，先中断。
再看一下昨天的日志grep -E '^2025-04-05' ../syslog > 04-04.log，这个日志只有1.5M。
日志锁定在04-05，导出一部分进行编辑。
看20000行和30000行，都是这个报错。看时间戳，确实是这个日志一直报错导致的syslog爆满。
#
真相大白
原因是我安装的tradingview没有网络套接字权限，一直报错Permission denied。报错频率很高，不停往syslog写入，写了几十个G，导致磁盘爆满。
具体原因在google上找到了同类问题。
https://community.brave.com/t/syslog-overflow/50248
和snap命令有关。
problem resolved, The problem was caused through the improper removal of brave application with the us of snap command. snap purge brave removes brave without disconnecting it from the kernel, should of run the obvious snap remove brave.
Do not install brave from the snap repository, use the steps given on the website through apt(-get)
问题是由于使用 snap 命令不正确地删除了应用程序，没有断开它与内核的连接。
#
事后预防
为了防止再发生这样的事，我给ubuntu装了个插件来看实时的硬盘速度。
