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

Raffa
  • 32,237
user183980
  • 531
  • 1
  • 4
  • 5

4 Answers4

58

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.

Raffa
  • 32,237
  • What is the purpose of NetworkManager-wait-online service? Need to know what could go wrong I disable this service – Govinda Sakhare Oct 06 '19 at 05:01
  • 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 Oct 06 '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 '20 at 23:05
  • @aap I have just updated the answer to address your concern. Thank you – Raffa Feb 17 '20 at 09:30
  • 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 Feb 17 '20 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 Feb 17 '20 at 17:05
  • @Raffa I am sorry, but your reply sort-of makes me a bit angry. Why? I have GitLab-CE running on my Ubuntu 18.04.0x LTS and for the heck of it I could not get it work... until I found about sudo systemctl list-jobs. Guess what was waiting the not letting gitlab-runsvdir continue? Right. plymouth-quit-wait.service. So after killing it using sudo killall plymouth that gitlab-runsvdir suddenly continued starting... I did not do anything before that except installing GitLab a long while ago. After the recent updates (up to 2 months) GitLab just stopped working. Now it works again. – Igor Feb 02 '21 at 23:15
  • 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 Feb 03 '21 at 09:58
  • I restarted the server several times because of updates - and it still works just fine. So while perhaps this might be temporarily, it works. I have no means to investigate gitlab-runsvdir, because I wouldn't understand it anyway. Thank you for your reply though :). – Igor Feb 04 '21 at 10:06
  • 1
    I don't know I used to have the same problem, but disabling plymouth DID reduce my bootup time. Is there an explanation to this? – User Apr 21 '21 at 13:52
  • I was having the same problem, but sometimes the boot will be faster and sometimes slower.I believe it is related to network-online.target and other network services waiting for network and hence Plymouth also showing more time. I am not bothered about it anymore, since i understand why this is happening based on answer from faffa – munish Feb 16 '23 at 02:51
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.

Mr.Michael.Schulze
  • 527
-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

Michal Przybylowicz
  • 3,672
-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

FloT
  • 2,326
RXDG14
  • 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 Oct 20 '20 at 10:18