Что такое dev-sda.device в systemd-анализе, могу ли я его отключить?
У меня Ubuntu 16.04 установлен на моем ноутбуке рядом с окнами. В systemd-analyze blame служба, называемая «dev-sda7.device», занимает слишком много времени. Как решить эту проблему или отключить ее?
Результат systemd-analyze time
Startup finished in 4.207s (firmware) + 4.576s (loader) + 3.466s (kernel) + 33.899s (userspace) = 46.149s
Результат systemd-analyze blame
16.326s dev-sda7.device
12.859s ufw.service
11.263s systemd-tmpfiles-setup-dev.service
7.935s NetworkManager-wait-online.service
3.203s keyboard-setup.service
2.736s vboxdrv.service
2.467s accounts-daemon.service
2.349s apache2.service
2.239s NetworkManager.service
2.163s ModemManager.service
1.963s lightdm.service
1.843s nmbd.service
1.749s samba-ad-dc.service
1.599s systemd-fsck@dev-disk-by\x2duuid-B053\x2dA56B.service
1.367s thermald.service
1.127s polkitd.service
1.112s systemd-journald.service
1.066s teamviewerd.service
1.007s udisks2.service
975ms apparmor.service
926ms plymouth-start.service
Результат cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda7 during installation
UUID=493cc833-193e-435d-840a-b862ca367fba / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda2 during installation
UUID=B053-A56B /boot/efi vfat umask=0077 0 1
# swap was on /dev/sda6 during installation
UUID=a49f56b1-53c3-4eaf-9460-0a221e59957a none swap sw 0 0
2 ответа
Вы не можете отключить его, потому что /dev/sda7 - это место, где установлен корневой раздел. В systemd все, что он может обрабатывать при загрузке, превращается в блок systemd. Затем вы можете делать что-то с ним (например, отслеживать тайминги в этом случае или зависеть от него для служб). В случае устройств цепочка выглядит следующим образом:
ядро загружает устройство и активирует его для системных часов для этого и создает для него узлы /dev/sdxy, а затем systemd активирует различные единицы монтирования, созданные из fstab, который затем запускает различные другие службы, ожидающие установки файловых систем и т. д.Это позволяет вам идентифицировать, что диск медленно активируется, но если вы не можете получить новый диск, вы не можете сделать этого.
Вы можете попробовать проанализировать критический путь и посмотреть, есть ли что-нибудь еще, что вы можете исправить:
systemd-analyze critical-chain [UNIT...] prints a tree of the
time-critical chain of units (for each of the specified UNITs or for
the default target otherwise). The time after the unit is active or
started is printed after the "@" character. The time the unit takes to
start is printed after the "+" character. Note that the output might be
misleading as the initialization of one service might depend on socket
activation and because of the parallel execution of units.
Пример:
graphical.target @10.868s
└─multi-user.target @10.868s
└─squid-deb-proxy.service @10.816s +51ms
└─network-online.target @10.814s
└─NetworkManager-wait-online.service @2.419s +8.395s
└─NetworkManager.service @2.243s +155ms
└─dbus.service @2.192s
└─basic.target @2.129s
└─sockets.target @2.129s
└─snapd.socket @2.127s +1ms
└─sysinit.target @2.127s
└─swap.target @2.127s
└─dev-disk-by\x2duuid-498d24e5\x2d7755\x2d422f\x2dbe45\x2d1b78d50b44e8.swap @2.119s +7ms
└─dev-disk-by\x2duuid-498d24e5\x2d7755\x2d422f\x2dbe45\x2d1b78d50b44e8.device @2.119s
Например, в моем случае сеть замедляет запуск.
Вы не можете отключить его, потому что /dev/sda7 - это место, где установлен корневой раздел. В systemd все, что он может обрабатывать при загрузке, превращается в блок systemd. Затем вы можете делать что-то с ним (например, отслеживать тайминги в этом случае или зависеть от него для служб). В случае устройств цепочка выглядит следующим образом:
ядро загружает устройство и активирует его для системных часов для этого и создает для него узлы /dev/sdxy, а затем systemd активирует различные единицы монтирования, созданные из fstab, который затем запускает различные другие службы, ожидающие установки файловых систем и т. д.Это позволяет вам идентифицировать, что диск медленно активируется, но если вы не можете получить новый диск, вы не можете сделать этого.
Вы можете попробовать проанализировать критический путь и посмотреть, есть ли что-нибудь еще, что вы можете исправить:
systemd-analyze critical-chain [UNIT...] prints a tree of the
time-critical chain of units (for each of the specified UNITs or for
the default target otherwise). The time after the unit is active or
started is printed after the "@" character. The time the unit takes to
start is printed after the "+" character. Note that the output might be
misleading as the initialization of one service might depend on socket
activation and because of the parallel execution of units.
Пример:
graphical.target @10.868s
└─multi-user.target @10.868s
└─squid-deb-proxy.service @10.816s +51ms
└─network-online.target @10.814s
└─NetworkManager-wait-online.service @2.419s +8.395s
└─NetworkManager.service @2.243s +155ms
└─dbus.service @2.192s
└─basic.target @2.129s
└─sockets.target @2.129s
└─snapd.socket @2.127s +1ms
└─sysinit.target @2.127s
└─swap.target @2.127s
└─dev-disk-by\x2duuid-498d24e5\x2d7755\x2d422f\x2dbe45\x2d1b78d50b44e8.swap @2.119s +7ms
└─dev-disk-by\x2duuid-498d24e5\x2d7755\x2d422f\x2dbe45\x2d1b78d50b44e8.device @2.119s
Например, в моем случае сеть замедляет запуск.