Oh neat, had no idea about that command. Looks like these two are the big time sinks:

6.340s systemd-udev-settle.service

6.232s NetworkManager-wait-online.service

Everything after that is under 250ms or so. Interesting that udev and network manager are taking so long during boot.

NetworkManager, and most other net daemons suck. I had almost lost hope till I found connman [1].

It's implemented by Intel and used in many mobiles. It has it's own _absurdly_ fast DHCP client. It manages many network interfaces flawlessly and it's really lightweight. Give it a try.

[1] https://01.org/connman

That same insanely fast DHCP client library now powers systemd-networkd[1]. We have been using it as the default on CoreOS for quite a number of releases now.

[1] https://coreos.com/blog/intro-to-systemd-networkd/

udevsettle is a hack that waits for the kevent queue to finish. I believe the justification for it was that certain volume and storage technologies on Linux act in a synchronous probing fashion that expect all devices to be up simultaneously before initializing. It's frequently mentioned as a bottleneck, including here: https://wiki.freedesktop.org/www/Software/systemd/Optimizati...

As for NetworkManager's wait online service, see what timeout has been set inside the unit file, and try lowering it. Though I suspect this might be yet another hack implemented as a synchronization point for network-dependent services to initialize properly, given just how finicky it is to define what a "network is up" state actually entails.

I'm still a systemd noob but I've heard there are ways to avoid blocking on network connectivity. Hopefully you'll forget about that part.

udev-settle seems to be a workaround LVM not being event driven enough http://freedesktop.org/wiki/Software/systemd/Optimizations/

https://bbs.archlinux.org/viewtopic.php?id=189369

Using arch, systemd boot time is now almost inexistant (but I have a tiny system with a SSD).