14

This is freshly installed machine running as dual boot over Win 10. For every reboot machine hangs for 15 secs as the plymouth service unable to start, due to some reasons.

ENv:-

    Manufacturer: Dell Inc.
    Product Name: Precision 5820 Tower
    Ubuntu 18.04 
    4.15.0-29-generic 
    vendor   : NVIDIA Corporation
    model    : GP104GL [Quadro P4000]

Below is the systemd-analyse output snippet

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

Here is the few snippet of boot logs

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).

Here is the delay

 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.

Graphics driver installed latest version - 415 from ppa repository

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

Can you let me know why there is a delay happening due to plymount-quit service? Please let me know is there any other info you would require for troubleshoot?

Is it related to hardware / software /grahics driver issue?

Thanks

17

Plymouth is not slowing your boot-up process! Plymouth is responsible for the boot-up splash screen. Please read Plymouth.

It loads the boot-up logo at the beginning of the boot-up process and then waits until the boot-up process has finished so it unloads the splash screen. That is all it does and that is why it has to run in parallel and co-exist throughout the whole boot-up process. It does not delay anything, it just waits.

That is exactly what is happening. No more and no less. Please take a look at the output you added to your question and carefully read the following:

● plymouth-quit-wait.service - Hold until boot process finishes up


How to Verify?

You can verify that plymouth-quit-wait.service is not holding anything back but the graphical login screen, by running the command:

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

which will output all the services that depend on plymouth-quit-wait.service (i.e services that are delayed by plymouth-quit-wait.service). On a freshly installed Ubuntu system, the output will be like this:

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

Which means only the graphical login screen is configured to wait for the plymouth-quit-wait.service and nothing else.

On the other hand if you list the services that plymouth-quit-wait.service is configured to wait for by running the command:

systemctl list-dependencies plymouth-quit-wait.service

the output would be almost every service that should run on boot and the output will look like this:

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

This confirms that plymouth-quit-wait.service is not slowing down anything but just running in parallel waiting for the system to fully boot and then it will hide the boot-up splash screen to bring up the graphical login screen.


To understand more.

Please run the following command in the terminal:

systemd-analyze plot > ~/SystemdAnalyzePlot.svg

Then, look for SystemdAnalyzePlot.svg in your home directory and run it in the image viewer or the Internet browser. You might need to enlarge the image so that you can read the processes names. It is worth checking and will give you a better understanding on how the boot-up process works.


You can, however, reduce your boot-up time by disabling NetworkManager-wait-online.service so plymouth has one less process to wait for. This can indeed reduce your boot-up time. To do this please follow the steps in this answer.


Oh... and please leave plymouth alone, it's not the one that makes you wait...it's the one that waits for you.

| improve this answer | |
  • What is the purpose of NetworkManager-wait-online service? Need to know what could go wrong I disable this service – Govinda Sakhare Oct 6 '19 at 5:01
  • 1
    @GovindaSakhare The purpose of the NetworkManager-wait-online.service is to wait for the network to come on-line before proceeding with the boot process. This is needed in case of for example servers that rely on network resources as part of the boot process ( eg. mounting remote drives ) or in the case of workstations that rely on the network to boot correctly ( eg. Thin Clients ). Otherwise, desktop users can disable NetworkManager-wait-online.service and network will connect normally after boot has finished minus the unneeded wait time. It is safe to disable in this case. – Raffa Oct 6 '19 at 14:06
  • 1
    I'm willing to believe it's /supposed/ to work as you say but on one of my machines the plot shows "plymouth-quit-wait.service (5min 39.552s)" and it would show longer except that I logged in via ssh and killed plymouth. About six other services seem to be waiting for plymouth to quit. The plot does not seem to indicate that plymouth is waiting for something specific. How can I find it? – aap Feb 16 at 23:05
  • @aap I have just updated the answer to address your concern. Thank you – Raffa Feb 17 at 9:30
  • 1
    @Raffa Then why does my machine boot in mere seconds when I remove "splash" from the kernel command line in /etc/default/grub? – aap Feb 17 at 13:36
3

I cannot say what else is necessary, but I can maybe give a workaround for you, so that the machine starts faster.

For me the most working solution was to disable the plymouth in grub with

sudo nano /etc/default/grub

and change the line GRUB_CMDLINE_LINUX_DEFAULT into

GRUB_CMDLINE_LINUX_DEFAULT="noplymouth video=SVIDEO-1:d"

After saving the change you must update the grub with

sudo update-grub

and then restart the machine.

| improve this answer | |
  • it works, that speed up my boot in 20secs – ejaenv Mar 5 at 8:59
0

You can disable this service by running the command :

sudo systemctl disable plymouth-quit-wait.service

From Service Description:

Hold until boot process finishes up

| improve this answer | |
  • Some explanation, maybe? – DanielM Aug 24 '19 at 11:35
  • Disabling plymouth-quit-wait.service is not going to help. Please see my answer here. Thank you – Raffa Aug 24 '19 at 18:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.