systemd (Was Re: tmpfs for strategic directories)

[Bastien Nocera]

On Wed, 2010-05-26 at 10:01 +0100, James Findley wrote:
> On 26/05/10 04:02, Casey Dahlin wrote:
> > On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
> >> On Tue, 25.05.10 10:21, Casey Dahlin (cdahlin at redhat.com) wrote:
> >>
> >>>
> >>> On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> >>>> On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> >>>>> Lennart Poettering wrote:
> >>>>>> So far response from the community has been very positive, but we didn't
> >>>>>> have a fedora-devel discussion about this yet, so we'll have to see
> >>>>>> whether we can somehow make the broader community as enthusiastic about
> >>>>>> the whole idea as I am. ;-)
> >>>>>
> >>>>> I, for one, think systemd should be the default ASAP.
> >>>>
> >>>> Perhaps the first time I can recall that we have agreed. ;)
> >>>>
> >>>> ~spot
> >>>
> >>> Any particular reason on either of your parts?
> >>>
> >>> Just about everything in systemd is either set to be in upstart (simpler
> >>> dependency syntax, xinetd-style service activation) or was discarded by it
> >>> years ago (cgroups are a dead end).
> >>
> >> Oh, is that so?
> >>
> >> Have you actually read the blog story I put together?
> >>
> >
> > Yes, but I'm going to go read it again just to be sure.
> >
> >> Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
> >> uh, it's not the only place where he is simply wrong and his claims
> >> baseless. In fact it works really well, and is one of the strong points
> >> in systemd. I simply see no alternative for it. The points Scott raised
> >> kinda showed that he never really played around with them.
> >>
> >> Please read up on cgroups, before you just dismiss technology like that
> >> as "dead end".
> >>
> >
> > I did. When upstart was about to use them. 2 years ago. We chucked them by the
> > following LPC.
> >
> > The problem we've found is that cgroups are too aggressive. They don't have a
> > notion of sessions and count too much as being part of your service, so you end
> > up with your screen session being counted as part of gdm.
> >
> > This is why setsid was added to the netlink connector.
> >
> >>> The assumption that just because its new means its more advanced is in this
> >>> case a bit misguided.
> >>
> >> Well, please read the blog story. I know it's long, but it should be an
> >> interesting read. The whole point of the blog story is to make clear the
> >> reason systemd exists is purely technical, and that we think our design
> >> is simply the better one.
> >>
> >
> > So you have:
> >
> > 1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
> > cared to submit the patch. We don't think its good enough by itself, hence the
> > rest of Upstart, but a socket activation subsystem that could reach as far as
> > systemd and even work standalone in settings where systemd can work is
> > perfectly within Upstart's scope. I'd be happy to firm up the design details
> > with you if you wanted to contribute patches.
> >
> > 2) Bus activation. Missed opportunity here to actually become the launchpoint
> > for activated services. I won't criticize that too much though, as its
> > usefulness is largely dependent on kernelspace DBus, which I've been trying to
> > bludgeon Marcel Holtmann into turning over to the public for a year now.
> >
> > 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.
> 
> 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 
> comparison, it takes 2.24 seconds to launch a thousand C hello world 
> programs.  So C is faster.  Just about.

Now run a loop, in C, which does the same thing.

$ time ./foo > /dev/null 

real	0m0.002s
user	0m0.001s
sys	0m0.001s

>   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 ;)

There's no compiling of startup scripts, read the blog again.

> 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.

Not very long multiplied by cold caches, and memory allocations and
frees, etc. The problem isn't that awk is launched, is that it's
launched a 100 times along with grep, cut, whatever kind of sticks and
strings you can get in shell text processing. That's hardly something a
modern init system should be doing.