Bug 1008188

What is the output of:

# systemd-analyze --fuzz=10ms critical-chain

[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
          └─...

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.

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.

so, What should I do?

(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?

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!

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.

[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
           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
            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
             4ms systemd-rfkill
             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?

[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

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