Remmina的一次暴走

原因未知，过程惊险，后果严重——记一次Remmina的暴走。

过程 ¶

孤的Debian忽然变得非常卡。

明明早上还很流畅，但一个午觉后，卡得难受。

用Monitor一看，CPU莫名其妙地跑得很高，数百GB的硬盘在以一个可见的速度逐渐减少。

临时解决 ¶

之前发现同类问题，是Docker导致的。 /var/lib/docker/aufs/目录，在某个容器运行时，异常增大。

这次不是。

htop中看到，竟然是systemd-journald.service和Remmina的CPU使用率过高。

杀掉二者，并且重启，症状解决。

然而，硬盘没有还给孤！

谁在占用硬盘 ¶

经过查找，是/var/log/目录下的三个文件，异常占用了空间。

$ ls -Ahl /var/log | grep G
total 184G
-rw-r----- 1 root              adm          62G Jul 12 14:57 messages
-rw-r----- 1 root              adm          60G Jul 12 14:57 syslog
-rw-r----- 1 root              adm         1.2G Jul 12 09:45 syslog.1
-rw-r----- 1 root              adm          62G Jul 12 14:57 user.log

由于log太大，不易查看。 并且，log的前后内容，都是正常的。

为了查看中央位置的异常，孤又使用了一招：

$ sudo tail -10000 /var/log/messages | head

结果发现，三个文件中，一行log重复了180GB！

Jul 12 14:10:48 debian remmina.desktop[22800]: WaitForSingleObject: unknown handle type 7160553448757878638

尸检报告 ¶

一切的根源，就是Remmina。

作为一个远程连接软件，在发生某不知名错误后，反复打印一行系统log，占用了大量机器资源。

而systemd-journald.service的异常，是由于systemd-journald-dev-log.socket导致的。 它只是受Remmina连累而已。

恭喜Remmina，刷新了软件故障的下限！

删除 ¶

$ cd /var/log
$ sudo rm messages* syslog* user.log*
$ sudo reboot

由于这几个系统文件的特殊性，删除后需要重启才能生效。 副作用是，丢失了近期的所有系统log。

另一种方法是：

$ sudo cat /dev/null > /var/log/messages

立即生效，但要分别写多个文件。