On 08/06/2015 22:40, Jonathan de Boyne Pollard wrote:
> As to whether opening server sockets early is a good idea: I'm not in
> a hurry to naysay. It achieves the stated effect. Arguably, indeed,
> it can be described as *what the system already does* if one has a
> lot of daemontools-style services spawned through UCSPI toolsets.
> They all start up early and in parallel, opening the sockets very
> first thing with something like tcpserver or tcp-socket-listen and
> *then* progressing to starting the main server program, thereby
> allowing clients to connect and block (rather than fail to connect
> and abend over and over) in parallel.
That's an interesting way of seeing it, and it certainly puts things
into perspective; but I don't think it's accurate.
Not every service can be run under a generic superserver. The ones
that can have one thing in common: they have no shared state among
various client connections. Also, since they fork a process per client
connection, they usually have little state overall, in order to avoid
computing the state with every connection.
So, services running under a generic superserver can pretty much
serve instantly. Read stdin, do stuff, write the result to stdout, done,
no prep time needed. If you're running sshd under a superserver, you'll
need a little prep, but it's only CPU cycles, that can hardly fail.
(sshd can still fail if for instance the host key cannot be found, but
honestly, people usually test their sshd and failures of that kind are
very rare.)
It's usually not a stretch to say that once the superserver has
listen()ed to the socket, the service is really ready. (At this point,
s6-???server4d sends its readiness notification.) Failures past that
point are uncommon, due to the simple nature of UCSPI servers.
Socket activation is a different beast. It's supposed to work with
any service, no matter what the daemon has to do before being ready
to serve, no matter how much state it has to build, no matter whether
it's depending on something that can fail.
The risk of failure-after-readiness is much bigger with socket-
activated services, because the early socket opening will apply to
services that do not necessarily play well or safely afterwards.
Would you open a socket early for your RabbitMQ server with its
legendary starting times?
--
Laurent
Received on Mon Jun 08 2015 - 22:17:49 UTC