启动时启动的开发循环服务是什么？

Question

启动后我跑systemd-analyze blame了，结果如下：

     21.596s systemd-journal-flush.service
     18.658s dev-sda8.device
     15.099s dev-loop33.device
     15.034s dev-loop19.device
     15.012s dev-loop34.device
     14.989s dev-loop21.device
     14.877s dev-loop15.device
     14.866s dev-loop26.device
     14.773s dev-loop27.device
     14.684s dev-loop30.device
     14.677s dev-loop32.device
     14.649s dev-loop35.device
     14.590s dev-loop25.device
     14.267s dev-loop23.device
     14.192s dev-loop24.device
     14.156s dev-loop29.device
     14.133s dev-loop16.device
     14.065s dev-loop31.device
     14.059s dev-loop28.device
     13.821s dev-loop20.device
     13.531s dev-loop22.device
     13.495s dev-loop14.device
     13.364s dev-loop18.device

这些dev-loopxx.device（xx表示数字）服务是什么？为什么要花这么多时间？它们与卡扣的安装有关吗？我可以通过禁用它们来减少启动时间吗？我正在运行 Ubuntu 18.04 和 Windows 10。

Answer 1

您可以使用 确定所有已安装快照的列表snap list，对于可以使用的挂载点和快照名称之间的关系systemctl status，mount以及losetup。

例如，在我的 Ubuntu MATE 18.04 LTS 上，我安装了以下快照：

$ snap list
Name                 Version           Rev   Tracking  Developer      Notes
core                 16-2.33.1         4917  stable    canonical      core
software-boutique    18.04.0-5b99b84   31    stable/…  flexiondotorg  classic
ubuntu-mate-welcome  17.10.23-e4f4c4c  169   stable/…  flexiondotorg  classic

他们创建循环设备如下：

$ systemd-analyze blame | grep dev-loop
          4.303s dev-loop4.device
          4.267s dev-loop2.device
          4.193s dev-loop0.device
          4.146s dev-loop3.device
           111ms dev-loop5.device

挂载点如下：

$ mount | grep snapd
/var/lib/snapd/snaps/core_4830.snap on /snap/core/4830 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/ubuntu-mate-welcome_169.snap on /snap/ubuntu-mate-welcome/169 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/software-boutique_31.snap on /snap/software-boutique/31 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_4650.snap on /snap/core/4650 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_4917.snap on /snap/core/4917 type squashfs (ro,nodev,relatime,x-gdu.hide)

让我们仔细看看dev-loop4.device：

$ systemctl status dev-loop4.device
? dev-loop4.device - /dev/loop4
   Follow: unit currently follows state of sys-devices-virtual-block-loop4.device
   Loaded: loaded
   Active: active (plugged) since Tue 2018-07-17 13:05:41 MSK; 4min 44s ago
   Device: /sys/devices/virtual/block/loop4

该文件夹/sys/devices/virtual/block/loop4包含非常有用的文件loop/backing_file，我们可以阅读其内容：

$ cat /sys/devices/virtual/block/loop4/loop/backing_file 
/var/lib/snapd/snaps/core_4650.snap

所以我们只是确定它/dev/loop4是由coresnap创建的。

但最简单的方法是使用losetup（参见man losetup）：

$ losetup 
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                         DIO LOG-SEC
/dev/loop4         0      0         1  1 /var/lib/snapd/snaps/core_4650.snap                 0     512
/dev/loop2         0      0         1  1 /var/lib/snapd/snaps/ubuntu-mate-welcome_169.snap   0     512
/dev/loop0         0      0         1  1 /var/lib/snapd/snaps/core_4830.snap                 0     512
/dev/loop5         0      0         1  1 /var/lib/snapd/snaps/core_4917.snap                 0     512
/dev/loop3         0      0         1  1 /var/lib/snapd/snaps/software-boutique_31.snap      0     512

希望这有助于更好地理解 Snaps 挂载点。

底线：通过使用 Snaps 来获得最新的软件，我们最终会付出更高的网络流量、更多的磁盘使用量和更慢的启动时间。如果您根本不想使用 Snap，请使用sudo apt-get purge snapd.