42

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

Improve this question

4 Answers 4

Reset to default
61

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
11
  • 4
    @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
    Commented Oct 6, 2019 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
    Commented Feb 16, 2020 at 23:05
  • 3
    @Raffa Then why does my machine boot in mere seconds when I remove "splash" from the kernel command line in /etc/default/grub?
    – aap
    Commented Feb 17, 2020 at 13:36
  • 1
    @aap The procedure described in your comment will not disable plymouth. It will still run as usual but will not display a splash screen. In fact this proves that plymouth is not responsible for the previous delay as it is still running anyway. What the procedure described in your comment might indeed solve is a miss-configured plymouth theme and this is a totally different issue which you can post in a new question to get the proper solution for it. Best regards
    – Raffa
    Commented Feb 17, 2020 at 17:05
  • 1
    @Igor That is a totally different matter and what you did is just a temporary work-arond and not the solution. I would investigate why gitlab-runsvdir behaves this way and fix gitlab-runsvdir not kill plymouth. The reason might be that gitlab-runsvdir depends on multi-user.target and needs to be configured to run after it or the status of gitlab-runsvdir might not be reported correctly and need to be fixed or some other reason. Please, do not get angry and post a new question instead with this information so that you get help fixing this gitlab-runsvdir issue. :) smile please.
    – Raffa
    Commented Feb 3, 2021 at 9:58
8

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
0
-2

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
2
  • 2
    Some explanation, maybe?
    – DanielM
    Commented Aug 24, 2019 at 11:35
  • 2
    Disabling plymouth-quit-wait.service is not going to help. Please see my answer here. Thank you
    – Raffa
    Commented Aug 24, 2019 at 18:44
-2

I was having boot time as 3-4 minutes because of this plymouth service taking 1 minute 30 seconds. What fixed my boot time was updating the kernel from 5.4(my default) to 5.9 in Ubuntu 20.

update your kernel

Improve this answer
1
  • 2
    As the other answers mention, the plymouth-quit-wait.service it not "the issue". The issue may be anything else, but installing an unsupported kernel may not be a good answer to everyone.
    – Artur Meinild
    Commented Oct 20, 2020 at 10:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .