Linked by diegocg on Sun 13th May 2012 23:48 UTC
Linux Lennart Poettering, the author of systemd, has announced: "I just put a first version of a wiki document together that lists a couple of easy optimizations to get your boot times down to [less than] 2s. It also includes a list of suggested things to hack on to get even quicker boot-ups."
Thread beginning with comment 517980
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: As a kernel dev myself
by ssokolow on Mon 14th May 2012 02:54 UTC in reply to "As a kernel dev myself"
Member since:

(4. Network delay)
I hesitate to add this one, since an unresponsive network should not really cause local bootup delays. But in fact I have seen cases of it where serially loaded processes get blocked due to a process waiting on DHCP or a network connection.

I've also occasionally run into parallel loading where neither the developers nor the system were smart enough to take prior boots into account, so the network init got done late enough that, before the network init finished, the init system had started to run out of tasks which could be run in parallel without waiting for the network to be up.

Reply Parent Score: 2

RE[2]: As a kernel dev myself
by Alfman on Mon 14th May 2012 04:52 in reply to "RE: As a kernel dev myself"
Alfman Member since:


Yea exactly.

The system will become idle while waiting for the network to come up, and then when it does it gets busy loading again. Ideally the loading would never stop/block until everything is fully loaded, even if the network isn't ready.

The problem can be more complex than meets the eye, since many daemons will fail when they call bind & listen if the network isn't up yet. Existing standards lack a way to have these processes load all their resources prior to the network becoming available. They'd probably need to poll for the network, which would only make the problem worse.

I did the following tests:

Terminal A

ifconfig br0:1 down
socat TCP-LISTEN:5555,bind= -
// above fails because network IP not yet available

ifconfig br0:1
socat TCP-LISTEN:5555,bind= -
// above succeeds

Terminal B
ifconfig br0:1 down
socat TCP-CONNECT: -
// connection fails

ifconfig br0:1
socat TCP-CONNECT: -
// connection succeeds!!

The last connection reveals an interesting fact. It is possible for a linux process (the second socat in Terminal A) to hold an open listen socket on an interface that is not yet enabled. If we could somehow get into this state on bootup, then it would solve our delima perfectly. Unfortunately though I'm not aware of a direct way to enter this state. Somehow we'd need the Linux API to permit the first command on Terminal A to succeed.

Edited 2012-05-14 05:01 UTC

Reply Parent Score: 2