logo标签列表

由于plymouth-quit-wait.service和Ubuntu 18.04，导致启动缓慢的问题。

bootdual-boot18.04systemdplymouth
这是一台新安装的机器，作为双系统与Win 10共存。每次重启时，由于某些原因，plymouth服务无法启动，导致机器挂起15秒钟。
环境：
    Manufacturer: Dell Inc.
    Product Name: Precision 5820 Tower
    Ubuntu 18.04 
    4.15.0-29-generic 
    vendor   : NVIDIA Corporation
    model    : GP104GL [Quadro P4000]

以下是systemd-analyse输出片段。
sudo systemd-analyze blame
     14.405s plymouth-quit-wait.service
      8.843s dev-sdb4.device
      8.049s NetworkManager-wait-online.service
      5.305s bolt.service
      4.889s snapd.service
      4.243s udisks2.service
      4.092s grub-common.service
      3.806s networking.service
      3.780s ModemManager.service
      3.325s dev-loop10.device
      3.295s apparmor.service
      3.190s dev-loop13.device
      3.162s accounts-daemon.service

这是启动日志的几个片段。
Feb 18 11:37:42  polkitd[876]: started daemon version 0.105 using 
authority implementation `local' version `0.105'
Feb 18 11:37:42  dbus-daemon[820]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Feb 18 11:37:42 systemd[1]: Started Authorization Manager.
Feb 18 11:37:42  accounts-daemon[801]: started daemon version 0.6.45
Feb 18 11:37:42  systemd[1]: Started Accounts Service.
Feb 18 11:37:42  systemd[1]: Received SIGRTMIN+20 from PID 394 (plymouthd).

这里是延迟。
 Feb 18 11:37:57  nvidia-persistenced: The daemon no longer has 
 permission to remove its runtime data directory /var/run/nvidia- 
 persistenced
 Feb 18 11:37:57  nvidia-persistenced: Shutdown (1206)
 Feb 18 11:37:57  systemd[1]: Stopped NVIDIA Persistence Daemon.
 Feb 18 11:37:58  gdm3: Child process -1088 was already dead.
 Feb 18 11:37:58  systemd[1]: Stopping User Manager for UID 121...
 Feb 18 11:37:58 systemd[1]: Received SIGRTMIN+21 from PID 394 (plymouthd)

sudo systemctl status plymouth-quit-wait.service
● plymouth-quit-wait.service - Hold until boot process finishes up
 Loaded: loaded (/lib/systemd/system/plymouth-quit-wait.service; static; vendor preset: enabled)
 Active: inactive (dead) since Mon 2019-02-18 11:37:58 +04; 7min ago
Main PID: 943 (code=exited, status=0/SUCCESS)

Feb 18 11:37:43  systemd[1]: Starting Hold until boot 
process finishes up...
Feb 18 11:37:58  systemd[1]: Started Hold until boot 
process finishes up.

已安装最新版本的图形驱动程序-来自ppa存储库的415版。
ii  nvidia-compute-utils-415                   415.27-0ubuntu0~gpu18.04.2          amd64        NVIDIA compute utilities
ii  nvidia-dkms-415                            415.27-0ubuntu0~gpu18.04.2          amd64        NVIDIA DKMS package
ii  nvidia-driver-415                          415.27-0ubuntu0~gpu18.04.2          amd64        NVIDIA driver metapackage
ii  nvidia-kernel-common-415                   415.27-0ubuntu0~gpu18.04.2          amd64        Shared files used with the kernel module
ii  nvidia-kernel-source-415                   415.27-0ubuntu0~gpu18.04.2          amd64        NVIDIA kernel source package
ii  nvidia-prime                               0.8.8.2                             all          Tools to enable NVIDIA's Prime
ii  nvidia-settings                            415.27-0ubuntu0~gpu18.04.1          amd64        Tool for configuring the NVIDIA graphics driver
ii  nvidia-utils-415                           415.27-0ubuntu0~gpu18.04.2          amd64        NVIDIA driver support binaries
ii  xserver-xorg-video-nvidia-415              415.27-0ubuntu0~gpu18.04.2          amd64        NVIDIA binary Xorg driver

请问您能告诉我为什么会因为 plymount-quit 服务而出现延迟吗？请问还需要其他信息来进行故障排除吗？
这是否与硬件/软件/图形驱动程序有关呢？
谢谢。
4个回答
Plymouth不会减慢您的启动过程！ Plymouth负责启动时的闪屏界面。请阅读Plymouth。
它在启动过程开始时加载启动标志，然后等待直到启动过程完成，然后卸载闪屏界面。这就是它所做的一切，也是为什么它必须在整个启动过程中并行运行和共存的原因。它不会延迟任何事情，只是等待而已。
这就是正在发生的事情。没有多余，也没有少。请查看您在您的问题中添加的输出，并仔细阅读以下内容：

● plymouth-quit-wait.service - 等待启动过程完成

如何进行验证？

您可以通过运行以下命令来验证plymouth-quit-wait.service只显示图形登录界面，而没有任何其他内容：

systemctl list-dependencies --reverse plymouth-quit-wait.service

这将输出所有依赖于plymouth-quit-wait.service的服务（即被plymouth-quit-wait.service延迟的服务）。在一个新安装的Ubuntu系统上，输出将会是这样的：

plymouth-quit-wait.service
● └─multi-user.target
●   └─graphical.target

这意味着只有图形登录界面被配置为等待plymouth-quit-wait.service，而其他任何东西都不会等待。
另一方面，如果您运行以下命令列出plymouth-quit-wait.service配置的等待服务：
systemctl list-dependencies plymouth-quit-wait.service

输出将几乎包括每个应该在启动时运行的服务，并且输出结果将如下所示：
plymouth-quit-wait.service
● ├─system.slice
● └─sysinit.target
●   ├─apparmor.service
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ├─grub-initrd-fallback.service
●   ├─keyboard-setup.service
●   ├─kmod-static-nodes.service
●   ├─plymouth-read-write.service
●   ├─plymouth-start.service
●   ├─proc-sys-fs-binfmt_misc.automount
●   ├─setvtrgb.service
●   ├─sys-fs-fuse-connections.mount
●   ├─sys-kernel-config.mount
●   ├─sys-kernel-debug.mount
●   ├─systemd-ask-password-console.path
●   ├─systemd-binfmt.service
●   ├─systemd-hwdb-update.service
●   ├─systemd-journal-flush.service
●   ├─systemd-journald.service
●   ├─systemd-machine-id-commit.service
●   ├─systemd-modules-load.service
●   ├─systemd-random-seed.service
●   ├─systemd-sysctl.service
●   ├─systemd-sysusers.service
●   ├─systemd-timesyncd.service
●   ├─systemd-tmpfiles-setup-dev.service
●   ├─systemd-tmpfiles-setup.service
●   ├─systemd-udev-trigger.service
●   ├─systemd-udevd.service
●   ├─systemd-update-utmp.service
●   ├─cryptsetup.target
●   ├─local-fs.target
●   │ ├─-.mount
●   │ ├─systemd-fsck-root.service
●   │ └─systemd-remount-fs.service
●   └─swap.target
●     └─swapfile.swap

这证实了plymouth-quit-wait.service并不会减慢任何事情，只是在并行运行等待系统完全启动，然后它将隐藏启动画面以显示图形登录界面。

要更深入了解，请在终端中运行以下命令：

systemd-analyze plot > ~/SystemdAnalyzePlot.svg

然后，在您的主目录中查找SystemdAnalyzePlot.svg，并在图像查看器或互联网浏览器中运行它。您可能需要放大图像以便能够阅读进程名称。这是值得检查的，并将帮助您更好地理解启动过程的工作原理。
你可以通过禁用NetworkManager-wait-online.service来减少启动时间，这样plymouth就少了一个等待的进程。这确实可以减少启动时间。要做到这一点，请按照this answer中的步骤操作。
噢...请别再提普利茅斯了，它不是那个让你等待的地方...而是等待着你的地方。
NetworkManager-wait-online服务的目的是什么？我想知道如果禁用此服务会有什么问题。 - Govinda Sakhare
2@GovindaSakhare NetworkManager-wait-online.service 的目的是在启动过程中等待网络上线后再继续进行。这在某些服务器依赖网络资源作为启动过程的一部分（例如挂载远程驱动器）或工作站依赖网络正确启动（例如瘦客户机）的情况下是必需的。否则，桌面用户可以禁用 NetworkManager-wait-online.service，网络将在启动完成后正常连接，无需等待时间。在这种情况下，禁用它是安全的。 - Raffa
1我愿意相信它应该按照你所说的那样工作，但在我的一台机器上，图表显示“plymouth-quit-wait.service（5分39.552秒）”，如果不是我通过ssh登录并杀掉plymouth，它会显示更长时间。大约还有六个其他服务似乎在等待plymouth退出。这个图表似乎没有显示plymouth在等待某个特定的东西。我该如何找到它？ - aap
@aap 我刚刚更新了答案以解决您的关注。谢谢 - Raffa
3@Raffa那为什么当我在/etc/default/grub的内核命令行中删除“splash”时，我的机器能在几秒钟内启动？ - aap
1@aap 您评论中描述的过程将不会禁用 plymouth。它仍将像往常一样运行，但不会显示闪屏画面。实际上，这证明了 plymouth 不是以前延迟的原因，因为它仍在运行。您评论中描述的过程确实可以解决的问题是一个错误配置的 plymouth 主题，而这是一个完全不同的问题，您可以在新的问题中发布它以获得适当的解决方案。最好的问候 - Raffa
@Raffa 对不起，但是你的回复有点让我生气。为什么呢？我在我的Ubuntu 18.04.0x LTS上运行着GitLab-CE，但是无论如何都无法让它工作... 直到我发现了sudo systemctl list-jobs。猜猜是什么在阻止gitlab-runsvdir继续运行？没错，就是plymouth-quit-wait.service。所以在使用sudo killall plymouth杀掉它之后，gitlab-runsvdir突然继续启动了... 在那之前我什么都没做，只是很久以前安装了GitLab。最近的更新（长达2个月）后，GitLab突然停止工作了。现在它又可以正常工作了。 - Igor
1@Igor 这是完全不同的问题，你所做的只是一个临时解决方案，而不是解决办法。我会调查为什么 gitlab-runsvdir 会出现这种情况，并修复 gitlab-runsvdir 不杀死 plymouth 的问题。原因可能是 gitlab-runsvdir 依赖于 multi-user.target，需要配置在其之后运行，或者 gitlab-runsvdir 的状态可能没有正确报告，需要修复，或者其他原因。请不要生气，而是发布一个新问题，附上这些信息，以便获得帮助解决 gitlab-runsvdir 的问题。:) 请微笑。 - Raffa
我因为更新几次重新启动了服务器，但它仍然正常工作。所以虽然这可能是暂时的，但它还是有效的。我没有办法调查gitlab-runsvdir，因为我也不会理解它。不过还是谢谢你的回复 :)。 - Igor
1我不知道，我以前也有同样的问题，但是禁用Plymouth确实减少了我的启动时间。这个现象有解释吗？ - User
我也遇到了同样的问题，但是有时启动会更快，有时会更慢。我相信这与 network-online.target 和其他网络服务等待网络有关，因此 Plymouth 也显示更多时间。我不再担心这个问题，因为我根据 faffa 的答案理解了为什么会发生这种情况。 - munish
我不能说还需要什么，但我可以给你一个解决办法，让机器启动更快。
对我来说，最有效的解决方案是在grub中禁用plymouth。
sudo nano /etc/default/grub

将行GRUB_CMDLINE_LINUX_DEFAULT更改为
GRUB_CMDLINE_LINUX_DEFAULT="noplymouth video=SVIDEO-1:d"

保存更改后，您必须更新grub。
sudo update-grub

然后重新启动机器。
您可以通过运行以下命令来禁用此服务：
sudo systemctl disable plymouth-quit-wait.service

从服务描述中：
等待引导过程完成
2可以解释一下吗？ - DanielM
2禁用plymouth-quit-wait.service不会有帮助。请在这里查看我的答案。谢谢。 - Raffa
我之前的开机时间是3-4分钟，因为这个plymouth服务需要1分30秒。解决我的开机时间问题的方法是将Ubuntu 20中默认的内核版本5.4更新到5.9。 更新你的内核
2正如其他答案所提到的，plymouth-quit-wait.service并不是“问题”。问题可能是其他任何事情，但安装一个不受支持的内核可能不是对每个人都是一个好答案。 - Artur Meinild