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."
Permalink for comment 517994
To read all comments associated with this story, please click here.
RE[2]: As a kernel dev myself
by Alfman on Mon 14th May 2012 04:52 UTC in reply to "RE: As a kernel dev myself"
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