snapd持续运行，引起jbd2/sda2-8持续访问硬盘，占用大量io

[sffred]

大体上就是我发现system load始终很高，经过反复排查，最终确定原因是snapd持续运行，jbd2/sda2-b持续访问硬盘造成的。在关闭snapd服务后，负载立即下降至0.00

在这期间，我检查过了日志，并发现ssh近期一直遭受爆破。在关闭ssh端口映射后负载依旧很高。可见此问题虽然有安全隐患，但似乎并非负载高的原因。

我不了解snapd服务。它是干嘛的？为什么会导致这样的异常磁盘读写（指示灯保持高频闪烁的状态）

[sffred]

补充一点，通过iotop查看到
Total DISK READ: 0.00 B/s | Total DISK WRITE: 853.28 K/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 1664.10 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
305 be/3 root 0.00 B/s 0.00 B/s 0.00 % 67.95 % [jbd2/sda2-8]
146 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.86 % [kworker/u8:3-events_power_efficient]
904 be/4 root 0.00 B/s 393.64 K/s 0.00 % 0.18 % snapd
960 be/4 root 0.00 B/s 262.43 K/s 0.00 % 0.12 % snapd
903 be/4 root 0.00 B/s 131.21 K/s 0.00 % 0.06 % snapd
1058 be/4 root 0.00 B/s 65.61 K/s 0.00 % 0.03 % snapd

[sffred]

目前初步定位问题是jbd2/sda2-8大量占用磁盘io，但是读写速度却是零。
这方面的网页不少，我查了好些网页
看到解决办法有：
1.升级内核。这个是最新的系统，无需升级。
2.更改磁盘提交频率。我暂时不敢更改，并且由于此前从未出现此类问题，最近也没有大的改动，暂时不想更改。
3.重启。重启后情况依旧如此。
4.更改mysql配置。我直接关闭了mysql，load仅仅有一定程度的下降，依然在1.0以上，可见mysql不是主要原因。
5.查看有哪些日志文件正在异常写入，并检查原因。我发现auth.log有异常写入，有人正在使用大量ip暴力破解我的root密码，我重新宽带拨号后ip更改，暂时逃过了攻击，但是load并未下降。
6.检查磁盘smart信息。检查完成，磁盘状态良好。
7.检查磁盘使用情况。磁盘仅仅使用了5%，只不过几个loop都是满的，但这似乎是正常状况？
以上，是我暂时能找到的内容，但是都未能解决问题。

[astolia]

在systemd环境下，大量的日志信息都是记录在/var/log/journal下面二进制文件了。如果你没有检查过，用journalctl查看一下是不是有程序在大量产生日志。
另外检查一下有没有可疑进程在运行

[sffred]

在systemd环境下，大量的日志信息都是记录在/var/log/journal下面二进制文件了。如果你没有检查过，用journalctl查看一下是不是有程序在大量产生日志。
另外检查一下有没有可疑进程在运行

谢谢，我之前看过文本日志，现在二进制日志看了下，主要篇幅也都是ssh被爆破。这个不知道是否有关联，但是貌似是没有的。
现在发现是snapd持续运行的缘故，关闭snapd服务负载就降下来了，重新启动又非常高。snapd在日志里也有一些。
Jun 05 22:35:16 ubuntu snapd[794]: AppArmor status: apparmor is enabled and all features are available
Jun 05 22:35:20 ubuntu snapd[794]: AppArmor status: apparmor is enabled and all features are available
Jun 05 22:35:21 ubuntu snapd[794]: daemon.go:343: started snapd/2.45 (series 16; classic) ubuntu/20.04 (amd64) linux/5.4.0-33-generic.
Jun 05 22:35:21 ubuntu snapd[794]: daemon.go:436: adjusting startup timeout by 45s (pessimistic estimate of 30s plus 5s per snap)
Jun 05 22:35:21 ubuntu systemd[1]: Starting Wait until snapd is fully seeded...
Jun 05 22:35:22 ubuntu systemd[1]: Finished Wait until snapd is fully seeded.
Jun 05 22:36:02 ubuntu snapd[794]: stateengine.go:150: state ensure error: Get https://api.snapcraft.io/api/v1/snaps/sections: net/http: request canceled while waiting for connection (Client.Timeout exceeded wh>
……
但是相当少，也看不出所以然来，似乎很正常

[sffred]

我最终解决这个问题的方式是卸载snapd。反正我也用不着

[TeliuTe]

20.04同样出现这个问题，卸载snapd后安静了，看synaptic里的软件包信息

Daemon and tooling that enable snap packages
Install, configure, refresh and remove snap packages. Snaps are
'universal' packages that work across many different Linux systems,
enabling secure distribution of the latest apps and utilities for
cloud, servers, desktops and the internet of things.

Start with 'snap list' to see installed snaps.

[Ping-Wu]

在 Ubuntu 里，用 df 时会发现系统里有一大堆莫名其妙的 snap loops，很不顺眼。更严重的问题是很多 snap 包打得并不是很好。例如 Ubuntu 里的 Chromium snap 包大家都在骂，也有不少 snap 包，如 VS Code 等，无法输入中文。Debian 就很实际，根本不用 snap：

ryzen@L32:~$ snap list
bash: snap: command not found

目前一些大宗的应用套件，尤其像 LibreOffice 等，都有 AppImage 版本，对 Linux 桌面系统使用者，非常方便。LibreOffice 的 AppImage 让我们在不同的系统，不同的机器，或不同的分割区里使用统一版本的 LibreOffice，连建构档也可以共同享用。AppImage 也让我们很方便的测试新的 LibreOffice 版本，对软件的开发也会有很大的帮助。