Ask Your Question

Fedora19 Improving boot time/disabling useless services

asked 2013-10-04 14:25:33 +0000

panguro gravatar image

updated 2014-02-01 11:57:52 +0000

Hi guys, for the first time i've installed a Linux Distro (latest Fedora 19 with gnome3). I like it very much but i want to improve the boot time. I think i can disable some useless service (for me) like bluetooth or wi-fi module (i use ethernet cable) and there are some errors too. Please answer with easy to understand language and examples of command to launch because i'm a newbie :)

This is what is shown with dmesg command (sorry i can't upload/attach it because it's first question here): ("long gap" are 8-11, 13-37, 37-271)

dmesg output can be found in fpaste.org

Anyone can help me? :)


EDITED (by Artur):

systemd-analyze blame:
8.676s plymouth-quit-wait.service
8.676s plymouth-quit-wait.service
4.406s firewalld.service
1.393s lvm2-monitor.service
1.364s accounts-daemon.service
1.338s systemd-fsck-root.service
1.246s NetworkManager-dispatcher.service
1.236s avahi-daemon.service
1.234s systemd-logind.service
1.207s rtkit-daemon.service
1.200s gdm.service
1.161s dmraid-activation.service
1.160s systemd-udev-settle.service
1.093s systemd-tmpfiles-setup-dev.service
 845ms plymouth-start.service
 806ms fedora-loadmodules.service
 747ms rpcbind.service
 741ms bluetooth.service
 498ms systemd-sysctl.service

After command by Arthur i gained some secs systemctl disable plymouth-quit-wait.service

Startup finished in 1.026s (kernel) + 1.396s (initrd) + 13.400s (userspace) = 15.822s
          7.326s plymouth-quit-wait.service
          3.674s firewalld.service
          2.485s lvm2-monitor.service
          2.074s accounts-daemon.service
          1.494s gdm.service
          1.457s systemd-logind.service
          1.449s avahi-daemon.service
          1.417s rtkit-daemon.service
          1.409s systemd-udev-settle.service
          1.226s systemd-fsck-root.service
           976ms systemd-tmpfiles-setup-dev.service
           964ms colord.service
           893ms dmraid-activation.service
           846ms plymouth-start.service
           716ms NetworkManager.service
           564ms fedora-loadmodules.service
           554ms systemd-tmpfiles-setup.service
           485ms chronyd.service
           463ms mcelog.service
           440ms systemd-udevd.service
           428ms plymouth-read-write.service
           421ms livesys-late.service
           390ms systemd-journal-flush.service
           347ms polkit.service
           286ms systemd-readahead-replay.service
           262ms systemd-sysctl.service
           236ms auditd.service
           192ms dev-disk-by\x2duuid-389aa575\x2d398b\x2d49dc\x2da8d7\x2dc46f30a2d36e.swap
           180ms lvm2-lvmetad.service
           152ms sys-kernel-debug.mount
           152ms systemd-udev-trigger.service
           151ms dev-hugepages.mount
           151ms dev-mqueue.mount
           125ms tmp.mount
           120ms udisks2.service
            85ms systemd-remount-fs.service
            74ms rpcbind.service
            69ms bluetooth.service
            62ms systemd-readahead-collect.service
            42ms livesys.service
            31ms systemd-user-sessions.service
            26ms sm-client.service
            22ms sendmail.service
            18ms abrt-ccpp.service
            14ms systemd-vconsole-setup.service
            12ms fedora-readonly.service
            10ms upower.service
             7ms NetworkManager-dispatcher.service
             6ms systemd-localed.service
             5ms sys-kernel-config.mount
             4ms systemd-update-utmp-runlevel.service
             4ms systemd-readahead-done.service
             4ms sys-fs-fuse-connections.mount
             1ms systemd-random-seed-load.service

After executing:

systemctl mask plymouth-quit-wait.service

(now it doesn't load "plymouth-quit-wait.service" on boot anymore, but i didn't gain any "real" seconds (only on logs) doing that.*

Startup finished in 1.021s (kernel) + 1.434s (initrd) + 13.024s (userspace) = 15.480s
      4.042s systemd-udev-settle.service
      3.810s colord.service
      3.676s firewalld.service
      2.039s lvm2-monitor.service
      1.494s systemd-fsck-root.service
      1.240s fedora-loadmodules.service
      1.041s systemd-tmpfiles-setup-dev.service
       885ms accounts-daemon.service
       851ms plymouth-start.service
       786ms systemd-sysctl.service
       723ms systemd-logind.service
       721ms avahi-daemon.service
       715ms chronyd.service
       615ms NetworkManager.service
       612ms mcelog.service
       612ms livesys.service
       603ms systemd-user-sessions.service
       598ms dmraid-activation.service
       563ms udisks2.service
       468ms systemd-udev-trigger.service
       460ms sys-kernel-debug.mount
       458ms dev-mqueue.mount
       458ms dev-hugepages.mount
       455ms lvm2-lvmetad.service
       432ms tmp.mount
       255ms systemd-udevd.service
       201ms gdm.service
       170ms rtkit-daemon.service
       159ms polkit.service
       148ms systemd-tmpfiles-setup.service
       125ms abrt-ccpp.service
       116ms systemd-tmpfiles-clean.service
       102ms auditd.service
        97ms livesys-late.service
        80ms systemd-readahead-replay.service
        68ms rpcbind.service
        64ms bluetooth.service
        61ms systemd-readahead-collect.service
        55ms plymouth-read-write.service
        49ms systemd-remount-fs.service
        26ms sm-client.service
        26ms sendmail.service
        13ms systemd-vconsole-setup.service
        10ms fedora-readonly.service
        10ms systemd-journal-flush.service
         9ms NetworkManager-dispatcher.service
         8ms upower.service
         8ms dev-disk-by\x2duuid-389aa575\x2d398b\x2d49dc\x2da8d7\x2dc46f30a2d36e.swap
         5ms sys-fs-fuse-connections.mount
         5ms systemd-update-utmp-runlevel.service
         5ms sys-kernel-config.mount
         4ms systemd-readahead-done.service
         1ms systemd-random-seed-load.service

After executing: (Thanks to Arthur and other repliers)

systemctl disable avahi-daemon.service systemctl disable sendmail.service systemctl mask bluetooth.service

Startup finished in 1.007s (kernel) + 1.426s (initrd) + 10.930s (userspace) = 13.363s
          4.176s firewalld.service
          2.584s lvm2-monitor.service
          2.391s accounts-daemon.service
          1.510s systemd-udev-settle.service
          1.382s systemd-fsck-root.service
          1.228s polkit.service
          1.146s gdm.service
          1.104s NetworkManager-dispatcher.service
          1.093s systemd-logind.service
          1.043s systemd-tmpfiles-setup-dev.service
          1.041s sys-kernel-debug.mount
          1.039s dev-mqueue.mount
          1.039s dev-hugepages.mount
          1.013s tmp.mount
           905ms dmraid-activation.service
           790ms rtkit-daemon.service
           752ms plymouth-start.service
           752ms colord.service
           655ms fedora-loadmodules.service
           568ms chronyd.service
           449ms systemd-udevd.service
           432ms systemd-tmpfiles-setup.service
           409ms rpcbind.service
           407ms plymouth-read-write.service
           394ms dev-disk-by\x2duuid-389aa575\x2d398b\x2d49dc\x2da8d7\x2dc46f30a2d36e.swap
           321ms livesys.service
           321ms mcelog.service
           310ms systemd-user-sessions.service
           304ms systemd-journal-flush.service
           269ms systemd-readahead-replay.service
           262ms systemd-sysctl.service
           214ms auditd.service
           183ms lvm2-lvmetad.service
           148ms systemd-udev-trigger.service
            69ms udisks2.service
            62ms systemd-readahead-collect.service
            58ms systemd-remount-fs.service
            43ms NetworkManager.service
            34ms livesys-late.service
            13ms fedora-readonly.service
            11ms systemd-vconsole-setup.service
             9ms abrt-ccpp.service
             9ms systemd-readahead-done.service
             8ms upower.service
             6ms sys-kernel-config.mount
             6ms sys-fs-fuse-connections.mount
             4ms systemd-update-utmp-runlevel.service
             1ms systemd-random-seed-load.service

All commands executed since fresh Fedora 19 x64 installation:

mv /var/log/journal /var/log/journal.org
 systemctl disable plymouth-quit-wait.service
systemctl mask plymouth-quit-wait.service
systemctl disable avahi-daemon.service
systemctl disable sendmail.service
systemctl mask bluetooth.service
systemctl mask rpcbind.service
systemctl enable systemd-readahead-collect systemd-readahead-replay (no advantage at the moment)

The main problem now is the black screen hanging on boot for 10 secs after Fedora logo and right before login screen

edit retag flag offensive close delete


Please post output of this commands: systemd-analyze; systemd-analyze blame

Artur Szymczak ( 2013-10-04 14:49:14 +0000 )edit

systemd-analyze; Startup finished in 1.019s (kernel) + 1.437s (initrd) + 15.145s (userspace) = 17.603s

panguro ( 2013-10-04 16:26:28 +0000 )edit

Improve boot time? That is a fast startup!

skytux ( 2013-10-04 16:36:14 +0000 )edit

systemd-analyze blame:8.676s plymouth-quit-wait.service 8.676s plymouth-quit-wait.service 4.406s firewalld.service 1.393s lvm2-monitor.service 1.364s accounts-daemon.service 1.338s systemd-fsck-root.service 1.246s NetworkManager-dispatcher.service 1.236s avahi-daemon.service 1.234s systemd-logind.service 1.207s rtkit-daemon.service 1.200s gdm.service 1.161s dmraid-activation.service 1.160s systemd-udev-settle.service 1.093s systemd-tmpfiles-setup-dev.service 845ms plymouth-start.service 806ms fedora-loadmodules.service 747ms rpcbind.service 741ms bluetooth.service 498ms systemd-sysctl.service

panguro ( 2013-10-04 16:37:13 +0000 )edit

I'm "in there" in about 56 secs (the motherboard takes 20s to load things and display O.S. list, so 36 secs to load), Before login screen (and after the Fedora logo disappear) it shows me a black screen without actions (apparently) for 10s. I think there are some problems with ipv6 on boot.

panguro ( 2013-10-04 16:43:00 +0000 )edit

3 Answers

Sort by » oldest newest most voted

answered 2013-10-05 18:55:38 +0000

skytux gravatar image

If the problem is the time taken by plymouth-quit-wait.service, then take a look here:


It was told that removing /var/log/journal fixes the problem. Indeed, it did for me.

Otherwise, I don't understand what is the problem here.



edit flag offensive delete publish link more


This indeed decreased my boot time ... WOW about 20 secs.. !

NikTh ( 2014-01-31 19:40:35 +0000 )edit

What was your boot time? :)

skytux ( 2014-01-31 20:39:54 +0000 )edit

41 secs, after I removed /var/log/journal/ it is 21 secs . Counted with systemd-analyze before and after - Fedora 20 !

NikTh ( 2014-01-31 21:04:02 +0000 )edit

answered 2013-10-06 08:57:08 +0000

First of all, I see that plymouth-quit-wait.service is still runing during boot, so please execute (as root): systemctl mask plymouth-quit-wait.service (this will disable this service).

More to that, according to your question do (all commands as root):

  • If you don't need dynamic firewall: systemctl disable firewalld.service
  • If you don't use lvm (check this by (as root) lvs, and post result here): systemctl disable lvm2-monitor.service and systemctl disable lvm2-lvmetad.service
  • systemctl disable avahi-daemon.service
  • systemctl disable dmraid-activation.service
  • systemctl disable livesys-late.service
  • systemctl disable livesys.service
  • systemctl disable sendmail.service
  • systemctl disable sm-client.service
  • If you don't need to connect (as a cient) to NFS server or NIS server, then disable: systemctl disable rpcbind.service
  • If you don't need Bluetooth: systemctl disable bluetooth.service
  • If you don't need time synchronization: systemctl disable chronyd.service
  • If you don't need Plymouth (this graphic-animation boot) systemctl disable plymouth-read-write.service and systemctl disable plymouth-start.service

If for some reasons, after reboot you still see any of disabled by you service in systemd-analyze blame, then redo command, but replace disable with mask, eg: systemctl disable rpcbind.service doesn't work, rpcbind is still running, then: systemctl mask rpcbind.service.

Again, all command execute as root (or at least by sudo).

After you done, and none of this service is running again, update your question with results from; systemd-analyze; systemd-analyze blame

edit flag offensive delete publish link more


Hi, thanks for reply. I've disabled a few services you wrote, but i didn't get any reasonable improvements. Is Thunderbird related to sendmail? or it doesn't need that service? Another thing: is it normal to wait 10 seconds (black screen) after that Fedora logo disappears and before the login screen?

panguro ( 2013-10-06 16:33:42 +0000 )edit

You don't need sendmail for using any MUA like thunderbird. And no, it is not normal.

Artur Szymczak ( 2013-10-06 16:42:56 +0000 )edit

Ok, then, what it could be? other than cutting off the 10 sec black screen i think there's nothing left to do to really improve the boot time.

panguro ( 2013-10-07 19:10:23 +0000 )edit

Please post on paste output of systemd-analyze plot

Artur Szymczak ( 2013-10-08 19:09:59 +0000 )edit

here it is: http://paste.fedoraproject.org/45253/

panguro ( 2013-10-08 19:58:59 +0000 )edit

answered 2013-10-04 16:42:13 +0000

sea gravatar image

updated 2013-10-04 17:43:21 +0000

Once you have a list to work,

with the output Artur Symczak asked for - i'd prefer the command output the other way around: systemd-analyze blame;systemd-analyze

You can disable them like this.

NOTE: This example works for me, but might not be applicable to your system!

for serv in ip6tables bluetooth \
    sendmail exim \
    livesys livesys-late \
    mdmonitor mdmonitor-takeover \
    lvm2 lvm2-monitor
    systemctl stop $serv.service
    systemctl disable $serv.service

These are common victims for my system, so i have them disabled upon first login.

Edit & update: According to your output, i'd applied them this way for you:

for serv in fedora-loadmodules plymouth-quit-wait \
        bluetooth systemd-fsck-root \
        avahi-daemon lvm2-monitor
    systemctl stop $serv.service
    systemctl disable $serv.service

lvm2-monitor and avahi-daemon might cause an issue - i dont know. If it was my system, id run this, but then its not mine - you do at your own risk.

edit flag offensive delete publish link more


Mmm i'd prefer to not risk! i think lvm2 and plymouth are necessary. Do You know a secure way to completely disable ipv6 on boot?

panguro ( 2013-10-04 19:29:44 +0000 )edit

You could always erease any ip6tables from your system, however, just disabling should suffice.

yum remove ip6tables vs. systemctl disable ip6tables.service

If you dont have a LVM setup, you can savely remove lvm2-monitor, however i'm not sure how much it affects raid systems...

sea ( 2013-10-04 20:08:20 +0000 )edit

First command doesn't work, the second one "systemctl disable ip6tables.service" seems to disabling it, but when i reboot it loads the same things and it takes exactly the same time to boot up. BTW thanks for replying :) ..other solutions?

panguro ( 2013-10-04 20:34:18 +0000 )edit

What do you mean by "doesnt work".. is there no package to remove or didnt you run yum remove ip6tables as root?

sea ( 2013-10-04 21:16:35 +0000 )edit

no package to remove

panguro ( 2013-10-04 21:45:30 +0000 )edit

Your answer

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

Add answer

[hide preview]

Use your votes!

  • Use the 30 daily voting points that you get!
  • Up-vote well framed questions that provide enough information to enable people provide answers.
  • Thank your helpers by up-voting their comments and answers. If a question you asked has been answered, accept the best answer by clicking on the checkbox on the left side of the answer.
  • Down-voting might cost you karma, but you should consider doing so for incorrect or clearly detrimental questions and answers.

Question tools

1 follower


Asked: 2013-10-04 14:25:33 +0000

Seen: 9,397 times

Last updated: Jan 31 '14