Avery Payne wrote:
> I suspect that you and Laurent would argue that I shouldn't be using
> sockets inside of ./run as it is, [...]
I don't really understand this whole explanation of your problem, at
first blush. So I'm reserving any judgement. But ...
Avery Payne wrote:
> If you have sequenced dependencies, can you truly gain a lot of time
> by attempting parallel startup? Is the gain for the effort really
> that important? Can we even speed things up when fsck is deemed
> mandatory by the admin for a given situation? Questions like these
> make me wonder if this is really a feasible feature at all.
The experience of Debian and Ubuntu was that far more was gained in
startup time reduction by switching the shell used to run all of those
scripts to the low-overhead Debian Almquist Shell from the Bourne Again
Shell, than was gained with parallelism with upstart and startpar.
Startup time is not the be-all and end-all, of course, and an excessive
focus upon it is detrimental. That said, the excessive delays in the
/etc/rc.delay mechanism on PC-BSD were what motivated me to get BSD
fully-nosh-service-manager-managed early on. It was delaying things on
the order of a minute or more, and the things that it was delaying were
things like setting the console screen size and keyboard layout, which
aren't exactly wait-for-the-network items. Objectively, it might not
belong as the first bullet point on the nosh blurb page. But from my
personal point of view it most certainly did. (-:
So whilst there are microscopic things that are drowned out by the
noise, there are also humungous whoppers, too.
The systemd dictum is that to truly take advantage of parallel startup,
one eliminates orderings as far as possible. Which is where "socket
activation" comes in. Part of "socket activation" is systemd opening
server sockets early, and passing them to the server processes that get
run. Because clients depend from the availability of the sockets,
rather than from the availability of the final services, clients and
servers can actually start in parallel, and the client is *not* declared
as dependent from the *service* being up.
From a UCSPI perspective, this mechanism is of course what the UCSPI
world has wanted from services all along: that they accept their
listening, or their connected, sockets as already opened standard file
descriptors. There's pressure on some of the more adamantly isolate
softwares to "be socket activatable", which of course means that (with
only a little bit of adjustment) they can also be plumbed into the UCSPI
way of working. Ironically, it's the converse of the situation where
pressure from the daemontools family world has led over the past couple
of decades to all sorts of programs (especially on the BSDs) gaining -D
or --don't-fork or --foreground or -F options, the benefit of which
systemd is reaping.
Now, as I noted elsewhere, UCSPI hasn't been limited to one little
family for some years. Even GNU inetd is in on the act, nowadays. This
is because UCSPI defines a way for a server program to receive its
already-open sockets and information about them. It doesn't get into
anything beyond the interface between the server program and what is
passing the sockets to it. So one big superserver, as inetd and systemd
are, can adhere to the UCSPI protocols just as much as a decentralized
system with lots of tcp-socket-listen/tcp-socket-accept or
s6-tcpserver4-socketbinder/s6-tcpserver4d programs can. (GNU inetd
does; systemd doesn't.) So don't get UCSPI mixed up with a scheme of
service management.
Where UCSPI comes in is in run programs: the mechanics of the run
program invoking tcp-socket-listen or s6-tcpserver4-socketbinder or
tcpserver and those in turn invoking the service-providing program.
Where it does not come in is service dependencies and ordering. "socket
activation" includes that under its umbrella because in the systemd
world sockets and the services that serve over them are two separate
classes of entity, treated as things (units) that can be individually
started/stopped/enabled/disabled. One starts a socket unit (auto-starts
it at boot time if it is enabled) and the socket unit conceptually
"activates" (i.e. starts) the related service unit, as and when. The
daemontools family has different concepts and design. One starts
services. It just so happens that some of them open sockets, listen,
and then run stuff, either immediately or when something happens.
Received on Mon Jun 08 2015 - 20:08:38 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC