systemd (Was Re: tmpfs for strategic directories)

James Findley sixy at
Wed May 26 12:27:19 UTC 2010

On 26/05/10 12:03, drago01 wrote:
> On Wed, May 26, 2010 at 12:53 PM, James Findley<sixy at>  wrote:
>> [...]
>> Sorry.  I like fast boots as much as the next person - this is just a
>> bad trade.  We only save ourselves (much) less than a second of boot
>> time, but turn a common and simple practice into a major headache.
>> If anyone has a bash/awk/whatever initscript that actually takes a
>> user-noticeable amount of time to run, this means that you've done
>> something badly wrong - it isn't the language at fault.  I would be
>> happy to help you fix this - just poke me on IRC.
> But the speed ups _add_ up ... lets say you save x, y, z time uints
> for script A, B and C ...
> you end up saving x+y+z.

Oh, I agree that they add up completely.  It's just that they don't add 
up to very much.  0.3 seconds for 93 spawns of awk, remember?

In terms of a helpful comparison let's assume you run 50 initscripts on 
boot (unlikely on a desktop - but lets go for worst case)

We will compare 3 things, and run each comparison 3 times to get a mean 

1) a poorly written bash script, that does horrible things like piping 
grep to awk (sidenote: this is always wrong, don't do it), spawning 
subshells, sourcing stuff when not required, etc

2) a clean bash script, that still calls awk but gets rid of unnecessary 
sources, subshells, etc.

3) an incredibly lightweight C program that just execv()'s the program

in all cases the program we will use is /bin/true - we just want 
something consistant and small.  Each is run 50 times in a loop.


1: 0.57 seconds
2: 0.20 seconds
3: 0.15 seconds

cleaning up the initscripts - which are often fairly poorly written - 
saves us nearly as much as writing them in C.  And even the worst case 
is only ~ half a second total across the entire boot process.

I just don't see any evidence at all that writing out initscripts in C 
really gets us anywhere useful in the real world, and I am extremely 
sure that it would be a significant pain in the ass to many, many people.

Yu want the initscripts to run faster?  Sure. lets clean them up. For a 
start /etc/init.d/functions is a mess that takes way to many CPU cycles 
for what it does - and includes a lot of functions that really aren't 
widely used enough to justify sourcing by _every_ initscript.
Massively obfuscating our boot process, however, is not the answer.


More information about the devel mailing list