[SOLVED]systemd-analyze startup delay problem

Question

Hello,
i have a problem that my systemd-analyze shows me "Bootup is not yet finished. Please try again later." when im up in my fully functional desktop, because it wants to wait 1min and 30 before it finishes the "boot"
systemd-analyze
Startup finished in 3.482s (kernel) + 1min 30.058s (userspace) = 1min 33.541s
the userspace always takes that amount of time. while it actually takes ~12 sec to load with all set up. working network and stuff like that.
systemd-analyze blame
1.426s dkms.service
215ms ModemManager.service
207ms NetworkManager.service
193ms systemd-fsck@dev-disk-by\x2duuid-c9582b14\x2de7f5\x2d4496\x2dbc09\x2d7be584a182f4.s
148ms systemd-fsck@dev-disk-by\x2duuid-37962c3c\x2dcb8c\x2d4bb4\x2da27a\x2d58e852dcb643.s
85ms systemd-logind.service
78ms mnt-stuff.mount
77ms upower.service
68ms systemd-tmpfiles-clean.service
54ms systemd-modules-load.service
52ms polkit.service
52ms systemd-udev-trigger.service
47ms systemd-binfmt.service
47ms kmod-static-nodes.service
44ms mnt-downloads.mount
44ms dev-hugepages.mount
44ms dev-mqueue.mount
44ms systemd-vconsole-setup.service
43ms systemd-sysctl.service
43ms sys-kernel-debug.mount
41ms udisks2.service
25ms [email protected]
24ms lm_sensors.service
15ms cpupower.service
14ms alsa-restore.service
10ms systemd-journal-flush.service
8ms systemd-remount-fs.service
6ms systemd-user-sessions.service
6ms systemd-tmpfiles-setup.service
5ms systemd-tmpfiles-setup-dev.service
5ms rtkit-daemon.service
4ms systemd-update-utmp.service
4ms sys-fs-fuse-connections.mount
3ms proc-sys-fs-binfmt_misc.mount
3ms tmp.mount
1ms sys-kernel-config.mount
1ms systemd-udevd.service
1ms systemd-random-seed.service
nothing weird here(i think)?
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 @1min 30.058s
└─multi-user.target @1min 30.058s
└─dkms.service @875ms +1.426s
└─basic.target @869ms
└─timers.target @627ms
└─systemd-tmpfiles-clean.timer @627ms
└─sysinit.target @626ms
└─sys-fs-fuse-connections.mount @8.291s +4ms
└─systemd-modules-load.service @61ms +54ms
└─systemd-journald.socket @58ms
└─-.mount @57ms
└─system.slice @101ms
└─-.slice @101ms
as you can see multi-user.target and graphical.target starting at 1.30 only... allthough i dont even understand why they start at that time..cause my graphical interface is long time up already as well as my user account.
here svg of systemd-analyze plot: https://dl.dropboxusercontent.com/u/28788188/boot.svg
if anybody has some idea what might cause this i would really appriciate the help.
its just seems a cosmetical issue though. since my actual boot is around 13 sec from grub to fully functional desktop.
Last edited by xpander (2013-09-27 14:45:30)

Answer 1

WonderWoofy wrote:
These kinds of delays can happen when a service is bound to a particular piece of hardware. 
So as an example the [email protected] uses "BindsTo=sys-subsystem-net-devices-%i.device".  So when you enable [email protected], the part between the '@' and '.service' is what it will use in place of the '%i' of the BindsTo parameter. 
This was a common problem when there was the change from the old kernel namespace used for network devices to the persistent udev naming scheme.  During installation (or any time one was in the live media), it would use dhcpcd@eth0, so it would make sense that enabling dhcpcd@eth0 would set you all up for a nice ethernet connection when you launch the system for the first time.  But then the 80-net-slot-names.rules udev file would change the interface name, making the BindsTo parameter time out after a while, since it would not be named something like enp2s0.
See if there are any failed units in the output of systemctl.  Of course you will have to do this after systemd claims to have "finished" booting.
thanks, will digg into that. i do have some renaming policy there.. cause i have eth0 shown in ifconfig for example
i remember i did something about it in the past, because i never got used with the new naming scheme.
anyway systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
fluidsynth.service loaded failed failed FluidSynth Daemon
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
and that fluidsynth is no issue. cause with this installed, it still does same. i have fluidynth uninstalled because my pulseadio doesnt work when that is enabled