Bug 1008188 - Boot takes too much time
Boot takes too much time
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
21
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-15 13:35 EDT by Neil
Modified: 2015-06-07 19:26 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-07 19:26:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil 2013-09-15 13:35:41 EDT
My Fedora 19 takes over 90 seconds or more to start, here is my systemd-analyze 

[duff@localhost ~]$ systemd-analyze 
Startup finished in 3.145s (kernel) + 2.692s (initrd) + 51.399s (userspace) = 57.236s



[duff@localhost ~]$ systemd-analyze blame
         32.396s firewalld.service
         32.177s chronyd.service
          2.756s lvm2-monitor.service
          1.977s fedora-loadmodules.service
          1.790s httpd.service
          1.683s colord.service
          1.670s lightdm.service
          1.649s systemd-tmpfiles-setup-dev.service
          1.271s var-tmp.mount
          1.238s NetworkManager.service
          1.156s systemd-fsck@dev-mapper-fedora\x2d02.service
          1.101s systemd-fsck@dev-sda1.service
           965ms tmp.mount
           944ms plymouth-start.service
           869ms systemd-fsck-root.service
           859ms systemd-logind.service
           820ms fedora-readonly.service
           784ms home.mount
           784ms dev-hugepages.mount
           783ms sys-kernel-debug.mount
           776ms dev-mqueue.mount
           713ms systemd-udev-trigger.service
           708ms polkit.service
           700ms rtkit-daemon.service
           681ms mcelog.service
           678ms systemd-user-sessions.service
           636ms systemd-fsck@dev-mapper-fedora\x2d04.service
           629ms systemd-fsck@dev-mapper-fedora\x2d03.service
           622ms systemd-sysctl.service
           567ms abrt-ccpp.service
           497ms dev-mapper-fedora\x2d01.swap
           459ms boot.mount
           410ms systemd-readahead-replay.service
           403ms iscsid.service
           386ms systemd-tmpfiles-setup.service
           304ms systemd-remount-fs.service
           217ms udisks2.service
           198ms systemd-readahead-collect.service
           198ms lvm2-lvmetad.service
           165ms sys-kernel-config.mount
           141ms sshd.service
           137ms systemd-udevd.service
            76ms plymouth-quit.service
            75ms plymouth-quit-wait.service
            55ms systemd-random-seed-load.service
            51ms accounts-daemon.service
            47ms plymouth-read-write.service
            27ms systemd-update-utmp-runlevel.service
            22ms rpcbind.service
            21ms upower.service
            21ms systemd-journal-flush.service
            13ms wpa_supplicant.service
             7ms systemd-readahead-done.service
             6ms systemd-vconsole-setup.service
             6ms sys-fs-fuse-connections.mount


halp
Comment 1 Harald Hoyer 2013-09-16 12:30:32 EDT
What is the output of:

# systemd-analyze --fuzz=10ms critical-chain
Comment 2 Neil 2013-09-16 12:33:11 EDT
[duff@localhost ~]$ systemd-analyze --fuzz=10ms critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @53.618s
└─multi-user.target @53.618s
  └─httpd.service @51.351s +2.266s
    └─network.target @51.346s
      └─wpa_supplicant.service @52.771s +6ms
        ├─basic.target @15.440s
        │ ├─sockets.target @15.440s
        │ │ ├─dbus.socket @15.440s
        │ │ │ └─sysinit.target @15.429s
        │ │ │   └─systemd-tmpfiles-setup.service @14.609s +816ms
        │ │ │     └─local-fs.target @14.607s
        │ │ │       └─var-tmp.mount @13.384s +1.221s
        │ │ │         └─dev-mapper-fedora\x2d04.device @12.466s
        │ │ ├─iscsiuio.socket @15.438s
        │ │ │ └─sysinit.target @15.429s
        │ │ │   └─...
        │ │ ├─iscsid.socket @15.437s
        │ │ │ └─sysinit.target @15.429s
        │ │ │   └─...
        │ │ ├─cups.socket @15.436s
        │ │ │ └─sysinit.target @15.429s
        │ │ │   └─...
        │ │ └─rpcbind.socket @15.434s
        │ │   └─sysinit.target @15.429s
        │ │     └─...
        │ └─paths.target @15.432s
        │   └─cups.path @15.432s
        │     └─sysinit.target @15.429s
        │       └─...
        └─dbus.socket @15.440s
          └─...
Comment 3 Harald Hoyer 2013-09-16 12:35:59 EDT
Your network.target waits until the network is online, which seems to be on wifi.

Seems like the httpd.service is pulling it in. Seems like the web server wants the network to be online first, before it starts.
Comment 4 Harald Hoyer 2013-09-16 12:37:31 EDT
Another question is, why the multi-user.target should start after the httpd.service.

I don't think the httpd.service should block the graphical login.
Comment 5 Neil 2013-09-16 13:22:03 EDT
so, What should I do?
Comment 6 Lennart Poettering 2014-02-23 11:40:56 EST
(In reply to Harald Hoyer from comment #4)
> Another question is, why the multi-user.target should start after the
> httpd.service.

Because multi-user.target is the target that is used to bring the full system up?

> I don't think the httpd.service should block the graphical login.

It doesn't. gdm doesn't wait for multi-user.target.

WPA supplicant took this long to start-up. Maybe you have some netzwork configured with that that it shall wait for?
Comment 7 Neil 2014-02-23 20:48:08 EST
I had that problem with Cinnamon environment and MATE environment, wasn't that slow on Gnome3 (it had a problem too with ConsoleKit after login).
I'm using Fedora 20 now, and I've seen fedora boot a lot faster in other systems, but mine is ok now, not too fast, not too slow, just fine.

Do you guys now if Manjaro use Systemd? I used manjaro and it boots really fast, in less than 10 seconds, while Fedora 20 starts in over 60~ seconds. 


I don't think that this is a bug anymore, at least it boot, on Fedora 19, Boot was about 2 minutes and even more.
Tried too disable Bluetooth (I don't have bluetooth) to make it a little bit faster (and other services) and, didn't have a big change, I had some weird thing happening for example (can't remember the services) 

Service X --------> 50's
Service Y --------> 3's

>Disable Service X
>Now Service Y is 50's


why? And it was different services (some lvm service and network service, if I can remember)


I don't have that system anymore, and I can't reply that on my new Fedora (20)

Thank you anyway!
Comment 8 Fedora End Of Life 2015-01-09 14:51:07 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Neil 2015-01-19 13:49:04 EST
[root@infinity duff]# systemd-analyze blame 
         20.975s systemd-journal-flush.service
          4.407s systemd-udev-settle.service
          2.663s systemd-udevd.service
          1.796s accounts-daemon.service
          1.675s tuned.service
          1.568s firewalld.service
          1.462s NetworkManager.service
          1.298s systemd-tmpfiles-setup-dev.service
          1.161s boot.mount
           983ms systemd-fsck@dev-disk-by\x2duuid-86dcacee\x2d3413\x2d4490\x2d9019\x2de755b5676f42.service
           947ms plymouth-start.service
           889ms polkit.service
           817ms fedora-import-state.service
           780ms colord.service
           742ms systemd-remount-fs.service
           689ms sys-kernel-debug.mount
           590ms plymouth-read-write.service
           567ms dev-mqueue.mount
           565ms dev-hugepages.mount
           557ms tmp.mount
           536ms fedora-readonly.service
           464ms systemd-journald.service
           344ms systemd-udev-trigger.service
           327ms rtkit-daemon.service
           306ms systemd-tmpfiles-setup.service
           243ms systemd-random-seed.service
           243ms kmod-static-nodes.service
           235ms home.mount
           218ms dmraid-activation.service
           195ms auditd.service
           178ms systemd-readahead-collect.service
           172ms dev-disk-by\x2duuid-d27f1674\x2db97d\x2d403f\x2da791\x2d72dc3ea5efd3.swap
           166ms systemd-readahead-replay.service
           138ms wpa_supplicant.service
           122ms user@1000.service
           122ms rsyslog.service
           119ms systemd-vconsole-setup.service
           118ms systemd-sysctl.service
           117ms udisks2.service
           108ms ModemManager.service
            97ms chronyd.service
            95ms abrt-ccpp.service
            90ms mcelog.service
            87ms systemd-logind.service
            82ms avahi-daemon.service
            56ms systemd-user-sessions.service
            40ms plymouth-quit.service
            40ms plymouth-quit-wait.service
            33ms user@985.service
            24ms upower.service
            16ms systemd-update-utmp-runlevel.service
            12ms systemd-readahead-done.service
            11ms sys-fs-fuse-connections.mount
            11ms systemd-update-utmp.service
             6ms systemd-rfkill@rfkill0.service
             4ms systemd-rfkill@rfkill1.service
             3ms systemd-journald-dev-log.socket
             3ms systemd-backlight@backlight:acpi_video0.service
             3ms systemd-backlight@backlight:intel_backlight.service
             2ms sys-kernel-config.mount


how it looks?
Comment 10 Neil 2015-01-19 13:49:57 EST
[root@infinity duff]# systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @28.271s
└─multi-user.target @28.271s
  └─NetworkManager.service @26.806s +1.462s
    └─firewalld.service @25.232s +1.568s
      └─basic.target @25.227s
        └─sockets.target @25.227s
          └─dbus.socket @25.227s
            └─sysinit.target @25.180s
              └─systemd-update-utmp.service @25.166s +11ms
                └─systemd-tmpfiles-setup.service @24.657s +306ms
                  └─systemd-journal-flush.service @3.676s +20.975s
                    └─systemd-remount-fs.service @2.919s +742ms
                      └─systemd-readahead-replay.service @2.751s +166ms
                        └─system.slice
                          └─-.slice
Comment 11 Neil 2015-01-19 13:51:05 EST
[root@infinity duff]# systemctl status auditd.service 
● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled)
   Active: failed (Result: exit-code) since lun 2015-01-19 13:42:17 COT; 8min ago
  Process: 569 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS)
  Process: 568 ExecStart=/sbin/auditd -n (code=exited, status=6)
 Main PID: 568 (code=exited, status=6)

ene 19 13:42:17 infinity systemd[1]: auditd.service: main process exited, c...ED
ene 19 13:42:17 infinity systemd[1]: Failed to start Security Auditing Service.
ene 19 13:42:17 infinity systemd[1]: Unit auditd.service entered failed state.
ene 19 13:42:17 infinity systemd[1]: auditd.service failed.
ene 19 13:42:17 infinity auditctl[569]: No rules
Hint: Some lines were ellipsized, use -l to show in full.

Note You need to log in before you can comment on or make changes to this bug.