[systemd-devel] Parallel startup with sockets and without killing the machine?

[microcai]

于 2011年05月10日 00:10, Scott James Remnant 写道:
> Hey, I've been reading through the documentation on systemd and the Mailing
> List Archives and have had some questions, so I figured I'd post them here.
> These might be fairly complicated or unusual cases, and there may be no good
> answers now, and maybe no good answers ever, but I'd still like to get an
> idea of what you think.
ok, i'm trying to express.
> 
> First up, parallel startup using sockets.
> 
> We know that the theory of this goes something like this: you have a service
> that many other services and processes depend on, and connect to via a
> socket. Rather than manually express that dependency in the configuration,
> you instead have the socket created by the init daemon in advance. Now you
> simply start the service and all of the other services and processes
> together, and let the blocking nature of those sockets (or the software
> polling a non-blocking socket) sort out the ordering for you.
> 
> This seems to assume that it's a free cost to start a service or process and
> have it block on a socket. But that isn't true, to get to the point where it
> connects to the socket, that service or process first has to be loaded from
> disk, its shared libraries mapped and relocated, it probably has to do a
> bunch of initialization including reading its own configuration files, etc.

No, we don't. It does not matter how long your server takes to fully
start up.

> That's fine for "low priority" services out of the critical path for user
> interaction, but not for services we need as fast as possible.
As fast as possible, this can only be done in systemd way. And service
won't lost any request. In traditional way, it lost.

> 
> The best example I can think is the X server itself. It's pretty much the
> definition of the critical path. Everything started before the X server are
> those basic system components needed to start the X server, I understand in
> systemd that this core part would be a different target to the X part and a
> dep of it. Everything started after the X server is up are components of the
> user's session that aren't totally critical for them to login or use their
> computer.

Currently, gdm wait for X to be ready before move on.
And to be worse, they use busy pull, not by some notification way.
In systemd way, gdm don't have to wait. And don't even have to X itself.
Just connect to X and X is there. No matter if X is currently running at
all.

> 
> It's during the X startup that things get interesting. There are a few
> discreet phases of it.
> 
> Firstly we have to spawn the X server, load the executable, map and relocate
> shared libraries, all of that jazz. You don't want anything else happening
> on the system alongside this, and you most certainly don't want every X
> client (Chromium/Firefox!) being loaded at the same time. The default
> behaviour of systemd seems to be to do just this :-(

No, systemd will not do this anyway. And even it really do this way,
what's the point? why X must been the only running process will it is
initializing ?

> 
> Secondly you have the period after the X server has "loaded" while
> it initializes but before it's "ready" to receive clients. In a perfect
> world this would be fast, but we all know that it isn't. In practice the X
> server takes countable seconds to do this work. This is a prime place in
> boot optimization to start other services alongside while X does its thang.
> But you wouldn't want to flood the system, as you don't want to delay X's
> startup, just use the spare resource to get more done. Can systemd discern
> "X has been spawned" and "X has initialized". Can systemd serialize services
> in this period (perhaps limited to one or two starting at a time)? Can it
> prioritize the order of those services in the X target?

Yeah , we have the *period* for every server. In upstart way, it use
complex  method to  indicate that stages. But with systemd ? We don't
even have to care about that.

> 
> Lastly there's the processes you'd start after X is up and services are
> connecting to it; again I assume this would be a different target - how
> would systemd know that X, and the critical X services/processes are fully
> up and that it can begin starting these. The important thing here is user
> latency - the startup of these services need to not noticeably impact system
> performance - not as simple as prioritization because the service itself may
> well need a different priority once its up. Any thoughts here?

This is no such thing called, XX service is initializing, or XX service
is up. No, systemd pressent us only one thing: There is XX service that
is connect-able. And the first connection may took long to response. But
you don't have to wait for the "running" stage any more. The XX servie
is connect-able throughout the way.  You don't have to care if XX is
running or not. Just connect to it.

> 
> Thanks,
> 
> Scott
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110510/c25c9514/attachment.pgp>