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
