启动缓慢:systemd-udev-settle.service

启动缓慢:systemd-udev-settle.service

最近,在 Google 上听说了 xubuntu 之后,我又从 Windows 切换到了 Linux,我非常喜欢它!
它快速又可靠。

但是,我想知道为什么我需要大约 1 分钟的时间来启动?

我在本论坛和其他地方都读过,大多数人都说,启动时间通常只有 20 - 30 秒

所以我做了一些研究,得出了

  $ systemd-analyze blame
  8.234s systemd-udev-settle.service
  8.198s dev-mapper-xubuntu\x2d\x2dvg\x2droot.device
  6.717s NetworkManager-wait-online.service
  5.170s ufw.service
  4.196s systemd-rfkill.service
  4.162s NetworkManager.service
  2.971s systemd-udevd.service
  2.830s ModemManager.service
  2.555s accounts-daemon.service
  2.019s thermald.service
  2.004s snapd.refresh.service
  1.801s networking.service
  1.790s systemd-tmpfiles-setup-dev.service
  1.726s grub-common.service
  1.572s systemd-journald.service
  1.536s systemd-modules-load.service
  1.448s irqbalance.service
  1.434s lightdm.service
  1.425s apport.service
  1.392s keyboard-setup.service
  1.377s upower.service
  1.287s plymouth-start.service
  1.126s lvm2-activation-early.service
  1.075s ondemand.service
   968ms apparmor.service
   917ms gpu-manager.service
   917ms polkitd.service
   911ms rsyslog.service
   857ms systemd-udev-trigger.service
   795ms systemd-logind.service
   755ms speech-dispatcher.service
   743ms colord.service
   705ms lm-sensors.service
   673ms dev-hugepages.mount
   666ms plymouth-read-write.service
   600ms avahi-daemon.service
   586ms systemd-backlight@backlight:acpi_video0.service
   557ms resolvconf.service
   518ms dev-mqueue.mount
   515ms sys-kernel-debug.mount
   485ms kmod-static-nodes.service
   479ms systemd-sysctl.service
   471ms console-setup.service
   433ms udisks2.service
   355ms lvm2-monitor.service
   352ms lvm2-activation.service
   350ms wpa_supplicant.service
   328ms lvm2-activation-net.service
   309ms binfmt-support.service
  8.234s systemd-udev-settle.service
  8.198s dev-mapper-xubuntu\x2d\x2dvg\x2droot.device
  6.717s NetworkManager-wait-online.service
  5.170s ufw.service
  4.196s systemd-rfkill.service
  4.162s NetworkManager.service
  2.971s systemd-udevd.service
  2.830s ModemManager.service
  2.555s accounts-daemon.service
  2.019s thermald.service
  2.004s snapd.refresh.service
  1.801s networking.service
  1.790s systemd-tmpfiles-setup-dev.service
  1.726s grub-common.service
  1.572s systemd-journald.service
  1.536s systemd-modules-load.service
  1.448s irqbalance.service
  1.434s lightdm.service
  1.425s apport.service
  1.392s keyboard-setup.service
  1.377s upower.service
  1.287s plymouth-start.service
  1.126s lvm2-activation-early.service

如您所见,列表中的前三项是导致启动缓慢的原因,我认为,我已经查找了有关的问题systemd-udev-settle,但找不到任何答案。

那么,systemd-udev-settle 是什么?我需要它吗?
我如何才能加快启动速度?

我的硬件:

  • 配备英特尔凌动 n570、320HDD 的旧电脑
  • 2 GB RAM(DDR3)运行 xubuntu 16.04(全新安装)

附言:我很抱歉我的英语不好,如果这个问题是重复的,请随时标记,我确实需要帮助。

任何形式的帮助都将不胜感激,谢谢!

答案1

由于我参加这个聚会已经晚了好几年,我会尝试为那些从搜索引擎进来的、出于相同原因对相同服务感兴趣的人(阅读:可能是未来的我?)更多地回答这个问题。

注意:这是不是在 ubuntu 系统上测试过,但应该与发行版无关(如果重要的话,我目前在 Fedora 上)。上次我检查时,只有问题仅限于 ubuntu(例如答案可以是通用的/发行版无关的),而且在过去 4 年中没有人试图回答这个问题。对于大多数使用 systemd 的 Linux 发行版(包括 Ubuntu,我确实测试了它的衍生发行版),这个答案应该是一样的

$ systemctl status systemd-udev-settle.service
● systemd-udev-settle.service - Wait for udev To Complete Device Initialization
....

该服务本身提供的描述相当模糊,没有提供太多信息。

据我所见,网上也没有太多关于这项服务的信息。

2015 年 5 月的一个 Debian Bug 邮件列表中有一条评论将其描述为:

我在 systemd-udev-settle masked 上的搜索告诉我它是关于“假块设备存储技术”(在我的情况下是 mdadm - raid)

同样,freedesktop.org systemd 优化页面(2013 年 5 月更新)指出:

  1. 确保不要使用任何虚假的块设备存储技术,例如 LVM(各种发行版默认安装,包括 Fedora),它们会导致 systemd-udev-settle.service 单元被拉入。解决设备枚举很慢、很不可靠,而且大多已经过时。由于 LVM(仍然)尚未更新以正确处理 Linux 的基于事件的设计,因此仍然需要解决设备枚举,但这会大大减慢启动速度。在 Fedora 上,使用“systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service”来摆脱所有这些存储技术。当然,如果您确实使用 LVM 安装了系统,请不要尝试此操作。(目前唯一可以正确处理这一切并且不需要解决设备枚举的虚假块设备存储技术是 LUKS 磁盘加密。)

由此,我得到的印象是,就像许多我尝试过的发行版上默认启用的其他几项服务一样,据我lvm2-monitor.service所知,这只有在使用 LVM 时才有用(对于那些不熟悉的人来说......这可能有点过于简单化,但有点像软件 RAID 或逻辑层,可以使多个硬盘假装成一个硬盘 - 换句话说,它不太可能被新手或甚至不知道 LVM 是什么的人使用)。 Fedora 33 和 Linux Mint 19 肯定是这种情况,我怀疑许多其他发行版也是如此,包括 ubuntu(它在 OP 的systemd-analyze blame输出中列出)。

类似于lvm2-monitor.servicesystemd-udev-settle.service似乎与 LVM 等“伪块设备存储技术”有关。debian 邮件列表提到它已在某人的系统上被禁用,因此禁用它似乎不太可能导致重大问题,除非有人专门设置了 LVM 或类似功能。如果您想禁用它,我建议您也禁用它(lvm2-monitor.service如果您还没有禁用的话)。

我目前没有在我的设置中使用任何 LVM 东西,并计划在接下来的一天左右有时间时测试禁用它。我会尝试报告是否遇到了任何严重问题/任何功能停止工作


更新:绝对不是系统关键问题(不影响启动/登录/图形内容),我仍然可以正常上网/访问我安装的所有 fstab 磁盘。~~我确实注意到我的用户空间时间稍微systemd-analyze高了一点(2-4 秒),但我不确定该值是平均值还是只是前一次启动的时间。我怀疑是后者,在这种情况下,可能只是由于硬件计时(例如 fstab 安装上线、连接到以太网等)导致的轻微但正常的波动。~~


更新 2:这最终稳定下来,比我干扰服务之前的初始时间少了大约 1-2 秒;可能是由于我之前提到的硬件时间波动较小。我在测试此服务的同时还禁用了其他几项服务。我在 Fedora 33 上禁用的服务完整列表(我也在 LM20 上测试/禁用了这些服务):

# don't run the following if you are booting your os from a
# a networked drive rather than a SSD/HDD
# (very very rare for home users):
sudo systemctl disable NetworkManager-wait-online.service
 
# don't run the following if you use dial-up internet:
sudo systemctl disable pppd-dns.service
 
# don't run the following if you use wifi:
sudo systemctl disable wpa_supplicant.service
 
# don't run the following 2 if you use LVM:
sudo systemctl mask lvm2-monitor.service
sudo systemctl mask systemd-udev-settle.service

最初,我还禁用(并屏蔽)accounts-daemon.service本网站将其列为“潜在的安全风险”。然而,经过多次调试,我最终发现这是导致我在 fedora-33 (cinnamon) 下 cinnamon-screensaver 和 cinnamon lock screen 损坏的直接原因。奇怪的是,这两个在 LM-20 下都运行良好。在我测试期间,这两个发行版都运行着 Cinnamon 4.8.6。

对于上述内容,我得到的唯一线索是一条日志条目~/.xsession-errors

(cinnamon-screensaver:2381): accountsservice-WARNING **: 02:43:13.941: ActUserManager: user (null) has no username (uid: -1)

经过大量搜索后,我看到了类似的错误文本redhat 错误报告碰巧提到了帐户服务,让我恍然大悟。运行sudo systemctl unmask accounts-daemon.service; sudo systemctl enable accounts-daemon.service; reboot屏幕保护程序后,锁屏又能正常工作了。


更新 3:我将作为相关主题提及的另一件事/我在之前的更新中暗示过,那就是启动时间可能会受到硬件的影响。将主操作系统安装到 SSD 上几乎总是比将其安装在 HDD 上更快,并且这两种方式几乎总是比从网络共享启动更快。但即使没有 SSD,HDD RPM(每分钟转数)也可能是一个因素。

但除此之外,我们假设您已将操作系统安装到可用的最快介质上。如果您有其他响应缓慢的硬件,您仍然可能会遇到一些启动延迟。我的 DVD 驱动器曾经出现故障,导致启动时间增加约 1 分钟。拔掉它有很大帮助(我不记得是驱动器还是电缆的问题,但值得检查这两种情况)。在其他设置中,我看到连接许多已定义挂载点的 HDD/etc/fstab也会导致速度变慢。如果您有额外的 HDD,我建议在 fstab 中为它们定义一个超时时间,介于 2-10 秒之间。

在 fstab 中,我使用以下选项进行挂载,以将其限制为每个 HDD 最多 3 秒(我建议至少将其保持在 2 秒以上):

# example, this will
# 1. mount the indicated ext4 HDD to /gaming
# 2. if the drive fails/is removed, don't abort the boot process
# 3. if the drive fails/is removed, don't spend more than 3s looking for it
# the default is that systemd will spend up to 90s PER DEVICE
# see https://wiki.archlinux.org/index.php/Fstab
# and https://www.freedesktop.org/software/systemd/man/systemd.mount.html
UUID=<my hdd's uuid>     /gaming     ext4    defaults,nofail,x-systemd.device-timeout=3s,nodev,user,exec 0 0
 
# something similar but for nfts (e.g. for a windows dual-boot)
UUID=<my other hdd uuid>   /media/d    ntfs-3g  defaults,nofail,x-systemd.device-timeout=3s,windows_names,locale=en_US.utf8,uid=1000  0 0

如果您怀疑这可能是一个因素/想要排除它。首先,记下您当前的启动时间。然后备份您的/etc/fstab并注释掉除和的安装之外的所有内容//home如果您的主分区位于不同的分区)。关闭电源并拔下所有 dvd/hdds/usb/etc,除了主驱动器(如果有主驱动器)和最低硬件 - 键盘 + 鼠标。然后启动并记下您的新启动时间。如果差异很大,请一次插入一个东西,直到找到罪魁祸首(这是我发现有故障的 dvd 驱动器/电缆所必须做的)。

资料来源:

  1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786942
  2. https://freedesktop.org/wiki/Software/systemd/Optimizations/

相关内容