userland boot time

Carsten Haitzler (The Rasterman) raster at
Mon Jan 21 13:56:57 CET 2008

On Mon, 21 Jan 2008 11:59:36 +0000 Andy Green <andy at> babbled:

> Hash: SHA1
> Somebody in the thread at some point said:
> > | sexy things that live in rc5 (X) until expensive stuff like udev (18s)
> > Check your kernel defconfig, it probably has a gazillion virtual
> > consoles, decrease those to like 8 and udev starts up almost
> > instantaniously. Related to that, more recent udevs use a different
> > method to create devnodes which is said to be faster.
> But point taken, I bet udev can be optimized down... there's alot of
> stuff in /etc/udev.d/rules or whatever it is that talks about hardware
> that isn't really going to ever appear, maybe that can help too.

in general everything we do at boot can be optimised down to some extent - we
just need to tackle it 1 thing at a time. even if we launch x early- how soon
will it be until they can make a call? that is a slight problem of deferring
init until after parts of the ui are up. we can get around this via psplash -
which we already do, BUT psplash can be very static and often wont do anything
for seconds on end - bar doesn't move. you wonder if it has hung. preferably we
need it to animate something all the time so you know something is alive and

other than that nixing all the silly things we do (like massive bash scripts and
functions that probably should be C programs as putting lots of logic in bash
is SLOOOOOW. last time i did a speed test bash was about 31,000 TIMES slower
than equivalent compiled C in doing things like if [ x ]; then blah; else
blah2; fi, interspersed with a bit of string and number math.

just a quick hard-facts check.

1. alsa-state - keep it. will need for starup audio bling thing so user knows
things are alive and working
2. dropbear - is started early - we can delay this until long after UI is up.
3. apmd - can wait until ui is up and kicking as well
4. dbus - keep. will need for full ui
5. syslog - call me a heretic, but i disabled syslong on my laptop to avoid iot
writing stuff to logs i will never read and eating up disk space, disk IO ,
disk wakeups and so on. why do we need syslog? (sure for debugging - but for a
target consumer device? if there is no way for the user to inspect the logs
from the gui... why have them?)
6. avahi-daemon - we can delay this until we bring up any form of network
interface. that can be delayed imho
7. bluetooth - keep it. would need for early-stage calls via headsets etc.
8. gsmd - keep it. duh!
9. pulseaudio - keep it. same as alsa above
10. usb-gadget - delay it until after gui is up?
11. rmnologin - if we delay dropbear, does it matter? remove it.
12. xserver-nodm - this is where the rest of the bootup pain begins. its a long
long long time between here and a gui you can actually do things with

a quick timing test (after the kernel has done scanning all the flash forever)
is about 50 seconds/ that's the sysv init stuff here that psplash hides. it's
about 20 seconds to go form x up to gui actually there.

so we need to address this in 2 parts. sysvinit etc. is only 1. the actual user
xsession is another. so /etc/X11/Xserver needs some love and attention too. and
thus /etc/X11/Xsession and /etc/X11/Xsession.d/*

... let the can of worms roll on.

Carsten Haitzler (The Rasterman) <raster at>

More information about the distro-devel mailing list