systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Wed, 26.05.10 10:01, James Findley (sixy at gmx.com) wrote:

> > 3) Cutting down on the forking by replacing some of the shell scripts... cool
> >     3a) With C code... really?
> >
> 
> Yeah.  I think this is odd too.
> The blog complains about how many awk spawns there are - but this looks 
> like a complaint that belongs in the 70's.
> 
> It really doesn't take long to launch awk. at all.  And most of the 
> things people are asking awk to do in shell scripts are very trivial, 
> requiring very little processing.

Maybe individually its not a problem. But doing that all the time (> 1000x
or so during boot) is just slow.

> using a simple for i in {1..1000}; do ... loop I can launch on this 
> rubbish old laptop a thousand awk processes in 3.35 seconds.  By 

It's no only about launching it. Take a couple of tools, pipe them
together, and actually execute some code with it.

> comparison, it takes 2.24 seconds to launch a thousand C hello world 
> programs.  So C is faster.  Just about.  But the complaint in the blog 
> is that awk is called 92 times.  By this metric that costs the user 0.3 
> seconds of CPU time.  To get rid of this horrible waste of resources we 
> are compiling all our startup scripts.... wait.  Something is wrong with 
> that picture ;)

Dude, this is not what I am suggesting, I want no "compiled" startup
scripts.

All I am saying that the majority of stuff should just be done in the
init system or the daemons themselves. And if there is something to
configure then do so in the .service file or in the daemon
configuration. But there is no point in keeping all in shell.

Also 2.24s is already quite a bit, if I may say so.

> Modern systems just don't take very long to spawn awk. Or sed. Or cut. 
> Or bash.  IMO this sort of tradeoff between speed and ease of use hasn't 
> been appropriate in 20 years.

Well, they actually do if you do that a thousand times.

> It's really not at all uncommon for me to need to modify an init script. 
>   There would be much rage if in order to do this I had to download the 
> SRPM, extract the init code, figure out what I needed to change, modify 
> it, recompile then install.

We are not taking control away from you: you can still configure the
.service file to your needs, and you have much more high-level controls
in there, and if you really want to you can still plug in a shell script
instead of the daemon binary itself and things will work just fine.

Also, much the code in the init scripts simply goes away without any
need for replacement if the init system is just smarter. You will have
to debug less, you will have to fix less, because there is less code,
and less buggy code, and less fragile shell code. You also will have
less duplication in each and every init script.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4