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