3 simple steps to make booting/shutdown faster...

Behdad Esfahbod behdad at behdad.org
Sun Feb 17 12:04:11 UTC 2008

On Sat, 2008-02-16 at 18:40 -0800, Arjan van de Ven wrote: 
> So I got a tad annoyed by why the initscript processing is (in my impatient perception) slow;
> most initscripts (in timing) only take like 0.1 second themselves after all.
> Turns out.. the rest of the initscript system had quite a bit of overhead.
> (More so on F7 than on F8, but still).
> Now... I made a bunch of tweaks to the 3 key files and this made things quite
> a bit faster; F8 is 50% slower than the new situation 
> (for a specific test, new code takes 0.275 seconds, F8 code takes 0.41 seconds).
> What I changed:
> * if you do if [ -f FOO -o -f BAR ] in bash, bash will look to see if BOTH files exist,
>   and then decides that since FOO exits, everything is fine and executes the if body. Looking for non-existing files
>   (first time) is expensive.. so splitting this kind of "if" in two reduces disk seeks and IO.
>   [this kind of split I had to do in a few places]

This should really be fixed in bash to short-circuit.

> * Don't let the initscripts change the VGA font; after all, this is done during early boot already.
>   Programming the VGA fonts is SLOW. (Note: in F7 this was done for each init script, in F8 things were
>   a tad, but not much, smarter than that)

I'd go as far as saying that unicode_start should only be called
from /etc/profile, not other bash invocations.

I have a hard time imagining why you hit it at all though, as only
interactive bash should run bashrc which in turn calls
into /etc/profile.d, or am I missing something?

> * Cache the information from /bin/consoletype. this info is used (and calculated with an exec!) all over the place;
>   the new code just sticks it in an environment variable. (well it was in one before, just it STILl got recalculated)
> * Check if the service is running before deciding if it's a good service; the common case for "telinit' is that it is and then
>   no further file IO on the service needs to be done. (and if it's not we need to check that regardless)
> * cache the value of "the user wants me to ask"; that's not changing so just stick that in a variable rather than looking at
>   the file every time. We still do look at the file IF the var is set, because the user might hit continue
> * don't call into "rhgb" if rhgb isn't on the kernel commandline (I have that off on all machines to make them boot faster).
>   rhgb got called several times, and isn't cheap, because each time it has to realize rhgb is really not there ;)
> * don't grep each script just to see how to pretty print it; assume a fedora quality script and if not, it's only a tad less pretty

Many moons ago I tried to reduce startup time on my fedora too.  I spent
most time on rc.sysinit though.  There's a lot that can be optimized
there.  I used bootchart to guide my search.  In the end I came up with
a short rc.behdad file that I could pass as init to kernel (!) which
would bring up just enough services to start gdm and then pass control
to /sbin/init.  And I reached something like 10 seconds from grub to
gdm.  I know there's a reason for every line of rc.sysinit, but a huge
lot of it can be optimized or postponed.

There were some plain silly bits.  For example look at /sbin/start_udev.
It implements a simple xargs in shell.  I remember that took a
measurable amount of time that simply went away by calling real xargs
when available.  I guess the __fgrep stuff in functions is supposed to
speed up, but I'm not sure it does so.

There was something really silly with xfs too, but xfs has gone for good

> Attached are the new files that implement these tweaks:
> /etc/rc.d/rc
> /etc/init.d/functions
> /etc/profile.d/lang.sh
> I hope others who are as impatient as I am find these tweaks as useful as I do :)
> Greetings,
>    Arjan van de Ven


"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759

More information about the fedora-devel-list mailing list